Re: [address-policy-wg] RE: The price of address space
That doesn't answer what you believe about all those deploying v6, for whatever reasons they are deploying it ... (Reasons that vary from environment to environment) If you want me to start listing the technical merits of IPv6 I would first point you to a plethora of sources - working groups, RFCs, whitepapers, new product lines and modes of communication, etc. - are you really asking for a single email to encompass 10+ years of work by hundreds+ people? ((I can (and do!) talk about IPv6 for a week at a time and am still time-constrained to present all of the how's, why's, and what's of IPv6 ... The majority of this time is presenting IPv6 things which are technically better than their IPv4 analogs)) FWIW, I would also include entire conversations about how NAT is not a panacea, and already breaks / limits application capabilities, carries 'costs' of it's own (both literal $, packet/forwarding overhead, security), etc. Again - not a single aspect that can readily be presented in a single email (feel free to ref. BEHAVE, for example) Again - I am not opposed to efforts to make NAT more transparent / functional ... PMP, ALD, UPnP, perhaps e2e, etc. - however I see none of these as a replacement for IPv6, nor any other aspect of IPv6 that is a deal-breaker. Imperfections that perhaps need to be mitigated (whether that is a protocol or an implementation 'fix' remains to be seen) - but nothing preventing me (or anyone else) from using v6 today (or, even more common - belated vendor support - ugh). /TJ ------Original Message------ From: Masataka Ohta To: TJ Evans Cc: address-policy-wg-admin@ripe.net Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] RE: The price of address space Sent: Jul 23, 2009 18:26 trejrco@gmail.com wrote:
I continue to be amazed at statements like: "Today, it is not necessary to deploy IPv6 at all."
So, you firmly believe that everyone deploying (or preparing to deploy) IPv6 today is ... What, wasting time? Wrong? Stupid?
As I said:
Technically speaking , so true. Today, it is not neccesary to deploy IPv6 at all.
valid counter arguments to me should have technical content. Masataka Ohta Sent from my Verizon Wireless BlackBerry
[I wonder where the policy discussion went....] [also, please fix your mailer, 200 column lines don't fit on most peoples displays...] trejrco@gmail.com wrote:
That doesn't answer what you believe about all those deploying v6, for whatever reasons they are deploying it ... (Reasons that vary from environment to environment)
If you want me to start listing the technical merits of IPv6 I would first point you to a plethora of sources - working groups, RFCs, whitepapers, new product lines and modes of communication, etc. - are you really asking for a single email to encompass 10+ years of work by hundreds+ people?
Yes, please, please point me to all that information, because there are not so many 'merits', especially technical. And if you claim there are then either I am missing something really big, or you are just preaching what you don't understand. Try coming up with 5 one-liner points where IPv6 > IPv4. I'll give you the sole real merit: More address space. For the rest, there are not any that are significant, as they all can be done with IPv4. Greets, Jeroen
Hi, On Fri, Jul 24, 2009 at 10:10:47AM +0200, Jeroen Massar wrote:
[I wonder where the policy discussion went....]
Well said. While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, I would indeed prefer to keep *this* list a bit more focused on *address policy related* topics: - developments that have impact on RIPE address policy work (so the economic views would fall into this) - weak points or operational problems with the current RIPE policies - not-yet-formal ideas for improving RIPE policy - comments to ongoing RIPE policy proposals "Whether or not IPv6 is technically superior to IPv4" is considered off-topic, as it has no real impact on our work: defining policies that help giving numbers to all those that need some, in a fair and impartial way. We need policies for those that want IPv6 numbers, and we need policies for those that want some of the remaining IPv4 numbers. thanks. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert Doering wrote:
While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, I would indeed prefer to keep *this* list a bit more focused on *address policy related* topics:
and we need policies for those that want some of the remaining IPv4 numbers.
The problem is that IPv4 address policy is affected a *LOT* by an answer to the following question: When IPv6 will be really deployed? Note that "never" can be a valid answer. So, it is impossible to evaluate most, if not all, IPv4 address policy proposals without assuming an answer to the question. If you want to stop the discussion on the question, we must accept multiple assumptions on answers to the question and never criticise proposals for their assumptions on the answers. Then, we can peacefully reach a uniform consensus on mutually incompatible multiple address policies. Do you want to have them? Or, shall we just ask the question to IETF and blindly accept their answer? Masataka Ohta
Masataka Ohta wrote:
Gert Doering wrote:
While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, I would indeed prefer to keep *this* list a bit more focused on *address policy related* topics:
and we need policies for those that want some of the remaining IPv4 numbers.
The problem is that IPv4 address policy is affected a *LOT* by an answer to the following question:
When IPv6 will be really deployed?
Depends on what you mean with that :) There are a lot of "depends" for a lot of questions. If you want a question answered you'll have to elaborate a lot on what you exactly mean. There are two known things though: - IPv4 address space is running short, and IANA will run out sooner or later, most likely in the next two years. - At that point in time your business has to have a solution. Possible solutions: - Do IPv6 - scales quite well, requires upgrades - Do IPv4 CGN - doesn't scale. Your pick on WHEN you are going to do that. Can do it today, can do it in ten years when the competition has your customers. Enjoy ;) Greets, Jeroen
On Fri, Jul 24, 2009 at 12:02:14PM +0200, Jeroen Massar wrote:
Masataka Ohta wrote:
Gert Doering wrote:
While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, I would indeed prefer to keep *this* list a bit more focused on *address policy related* topics:
and we need policies for those that want some of the remaining IPv4 numbers.
The problem is that IPv4 address policy is affected a *LOT* by an answer to the following question:
When IPv6 will be really deployed?
Depends on what you mean with that :)
amen. Ohta-san, please come visit. You will find that unless your network devices are capabile of IPv6 transport, you will have no connectivity. with the exception of the IVI box and the DNS server, nothing has an IPv4 address. the other 40+ devices onnet are all runing native IPv6. I would say that this is emperical evidence of IPv6 deployment. Would you disagree? --bill
Jeroen Massar wrote:
- At that point in time your business has to have a solution. Possible solutions: - Do IPv6 - scales quite well, requires upgrades - Do IPv4 CGN - doesn't scale.
CGN not scale? NAT, in general including CGN, does scale to the extent to make IPv6 not necessary.
Your pick on WHEN you are going to do that. Can do it today, can do it in ten years when the competition has your customers. Enjoy ;)
If it is 10 years, we should use not IPv6 but something else. Masataka Ohta PS As you don't accept the answer "never", discussion on whether it will actually be "never" or not is inevitable.
Masataka Ohta wrote:
Jeroen Massar wrote:
- At that point in time your business has to have a solution. Possible solutions: - Do IPv6 - scales quite well, requires upgrades - Do IPv4 CGN - doesn't scale.
CGN not scale?
NAT, in general including CGN, does scale to the extent to make IPv6 not necessary.
It scales on paper, till you start using it. 1 IPv4 address, 65k TCP ports, if one user opens maps.google, he uses 200 TCP sessions on average, thus 65k/200 == 332 users per IPv4 address. Yes, indeed, really "scales" well. CGNs will btw only delay the inevitable. (On the subject of CGN and content-restricting ISPs for CP and other 'legal reasons': I would actually simply go with an HTTP-only proxy. Nothing difficult, nothing to evade unless people start encoding their stuff inside HTTP)
Your pick on WHEN you are going to do that. Can do it today, can do it in ten years when the competition has your customers. Enjoy ;)
If it is 10 years, we should use not IPv6 but something else.
You can do that, your competition will love you for it. [..]
As you don't accept the answer "never", discussion on whether it will actually be "never" or not is inevitable.
Give me one valid technical reason why I would accept "never"? Greets, Jeroen
Jeroen Massar wrote:
NAT, in general including CGN, does scale to the extent to make IPv6 not necessary.
It scales on paper, till you start using it.
1 IPv4 address, 65k TCP ports, if one user opens maps.google, he uses 200 TCP sessions on average, thus 65k/200 == 332 users per IPv4 address.
200 is a peak of an extra ordinary application and, even with the application, unused ports are closed quickly that dynamic allocation of ports save average port requirements. Note also that consumption of extra ordinary number of port is a state maintenance problem for NAT between 6 and 4.
Yes, indeed, really "scales" well.
Yes, of course.
CGNs will btw only delay the inevitable.
It is inevitable that protocols have lifetime, of course. A problem is that the lifetime of IPv6 has already expired.
(On the subject of CGN and content-restricting ISPs for CP and other
Let's not discuss it here, because there are alternative ways to NAT.
If it is 10 years, we should use not IPv6 but something else.
You can do that, your competition will love you for it.
Considering that route aggregation is also an important goal of address policy, which IPv6 failed to address, we do need something else.
As you don't accept the answer "never", discussion on whether it will actually be "never" or not is inevitable.
Give me one valid technical reason why I would accept "never"?
Because, as you failed to argue against, it is no better than IPv4 with NAT. Masataka Ohta
Masataka Ohta wrote: [..]
You can do that, your competition will love you for it.
Considering that route aggregation is also an important goal of address policy, which IPv6 failed to address, we do need something else.
That is a routing issue, not an addressing issue (which is what IPv6 solves), and it definitely is not a policy issue; as such it doesn't below on this list anyway.
As you don't accept the answer "never", discussion on whether it will actually be "never" or not is inevitable.
Give me one valid technical reason why I would accept "never"?
Because, as you failed to argue against, it is no better than IPv4 with NAT.
We'll talk further when you realize what happens when you are trying to SSH from your cozy island vacation resort to your computer at home which is behind several layers of NAT (at least the one at home, as your ISP will still only give you 1 ISP-NATted address and thus also the ISP NATted one, possibly a couple of extra as the ISP didn't get any addresses either). Greets, Jeroen (Small hint: There is a reason why PuTTY has IPv6 support :)
Jeroen Massar wrote:
Considering that route aggregation is also an important goal of address policy, which IPv6 failed to address, we do need something else.
That is a routing issue, not an addressing issue (which is what IPv6 solves), and it definitely is not a policy issue; as such it doesn't below on this list anyway.
I'm afraid you confuse routability and aggregation. As is written in RIPE NCC activity plan 2009 http://www.ripe.net/ripe/docs/ap.html To provide a fair, impartial distribution of Internet number resources guided by the RIPE community policies based on the goals of uniqueness, conservation and aggregation aggregation is a goal of address policies.
We'll talk further when you realize what happens when you are trying to SSH from your cozy island vacation resort to your computer at home which is behind several layers of NAT (at least the one at home, as your ISP will still only give you 1 ISP-NATted address and thus also the ISP NATted one, possibly a couple of extra as the ISP didn't get any addresses either).
That is not a essential problem of NAT, because situation is no worse than with IPv6 ISPs not giving stable addresses to its customers. If you pay some ISP enough amount of money, the ISP will give you a fixed IPv6 address or a fixed IPv4 address+port. A fundamental problem of NAT was that end hosts did not know its public address and that end hosts did not restrict source port numbers, both of which are solvable and were solved. Masataka Ohta
Greets, Jeroen
(Small hint: There is a reason why PuTTY has IPv6 support :)
Masataka Ohta wrote:
Jeroen Massar wrote:
Considering that route aggregation is also an important goal of address policy, which IPv6 failed to address, we do need something else.
That is a routing issue, not an addressing issue (which is what IPv6 solves), and it definitely is not a policy issue; as such it doesn't below on this list anyway.
I'm afraid you confuse routability and aggregation.
As is written in RIPE NCC activity plan 2009
http://www.ripe.net/ripe/docs/ap.html
To provide a fair, impartial distribution of Internet number resources guided by the RIPE community policies based on the goals of uniqueness, conservation and aggregation
aggregation is a goal of address policies.
Is that goal not reached anywhere then? The community set the policy for giving out IPv6 PA and PI. Aggregation is done on the size given out as a PI or PA block. If you have problem with those policies then write up a new policy and submit it, that is an appropriate thing to do on this list.
We'll talk further when you realize what happens when you are trying to SSH from your cozy island vacation resort to your computer at home which is behind several layers of NAT (at least the one at home, as your ISP will still only give you 1 ISP-NATted address and thus also the ISP NATted one, possibly a couple of extra as the ISP didn't get any addresses either).
That is not a essential problem of NAT, because situation is no worse than with IPv6 ISPs not giving stable addresses to its customers.
DynDNS solves that problem perfectly fine.
If you pay some ISP enough amount of money, the ISP will give you a fixed IPv6 address or a fixed IPv4 address+port.
This seems to be a CASH issue then, not a technical issue. Technically this is already solved as there are SRV records in existence, just not that many applications actually use them. What is an issue though is that at one point there will not be any IPv4 addresses for new organizations to use. IPv6 then still keeps on working. IPv4 won't, as you won't get a new address.
A fundamental problem of NAT was that end hosts did not know its public address and that end hosts did not restrict source port numbers, both of which are solvable and were solved.
Indeed, IPv6 has been solving these issues for a long time already. Greets, Jeroen
Jeroen Massar wrote:
If you have problem with those policies then write up a new policy and submit it, that is an appropriate thing to do on this list.
Poor aggregation is a problem of protocol, not policy.
That is not a essential problem of NAT, because situation is no worse than with IPv6 ISPs not giving stable addresses to its customers.
DynDNS solves that problem perfectly fine.
As you are assuming cooperation between your server and an external relay of DynDNS servers, you can do anything with your server even if it is located behind legacy NAT with no port forwarding.
If you pay some ISP enough amount of money, the ISP will give you a fixed IPv6 address or a fixed IPv4 address+port.
This seems to be a CASH issue then, not a technical issue.
If you assume DynDNS free, you can also assume fixed IPv4 address+port free.
What is an issue though is that at one point there will not be any IPv4 addresses for new organizations to use.
That is the point. Unless NAT is mandated and IPv4 allocation is reduced, there will be the point, before we are ready to migrate to new Internet protocol to solve aggregation problem.
IPv6 then still keeps on working.
In the real world, IPv6 Internet is not yet working at all.
A fundamental problem of NAT was that end hosts did not know its public address and that end hosts did not restrict source port numbers, both of which are solvable and were solved.
Indeed, IPv6 has been solving these issues for a long time already.
Not at all. As dual stack approach being abandoned, NAT between 6 and 4 causes the same problem. The only solution is to use end to end NAT or equivalent technology (such as port-wise routing) with modified end hosts in pure IPv4 world. Masataka Ohta
Hi, On Fri, Jul 24, 2009 at 06:39:41PM +0900, Masataka Ohta wrote:
Gert Doering wrote:
While I do quite enjoy the occasional IPv6/IPv4 advocacy discussion, I would indeed prefer to keep *this* list a bit more focused on *address policy related* topics:
and we need policies for those that want some of the remaining IPv4 numbers.
The problem is that IPv4 address policy is affected a *LOT* by an answer to the following question:
When IPv6 will be really deployed?
Note that "never" can be a valid answer.
This question is something that we simply cannot answer - and even if we could, it doesn't matter. Some people do deploy IPv6 today (whether or not they "really" deploy IPv6 does not matter at all, as long as they need addresses for whatever they do), so we need IPv6 address policies to enable those to do so. Other people deploy IPv4 today, and will continue to do so, for a time frame unknown to me. So we also need IPv4 address policies. If the IPv4 pool runs out, we need to handle this, policy-wise. If it doesn't, because the Internet stops growing, everybody does NAT, or everybody migrats to IPv6, we don't - but we won't know in advance, so it is useful to have a plan for the case that it does run out. So - while the answer of your question might matter a lot to the well-being of the Internet at large, it has hardly any relevance on the policy work we do: "distribute numbers to those people that need numbers for their work, in an open, fair, and transparent way". (Note everybody agrees whether we do an optimum job here, and much of what we do turns out years later to be a "good" or "bad" decision, but that's the problem with todays crystal balls) Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert Doering wrote:
Other people deploy IPv4 today, and will continue to do so, for a time frame unknown to me. So we also need IPv4 address policies.
And the time frame is the essential factor for IPv4 address policies.
If the IPv4 pool runs out, we need to handle this, policy-wise. If it doesn't, because the Internet stops growing, everybody does NAT, or everybody migrats to IPv6, we don't - but we won't know in advance, so it is useful to have a plan for the case that it does run out.
Not. As is written in RIPE NCC activity plan 2009 http://www.ripe.net/ripe/docs/ap.html To provide a fair, impartial distribution of Internet number resources guided by the RIPE community policies based on the goals of uniqueness, conservation and aggregation we must know where the goal of conservation is. When (including "never") IPv4 pool runs out strongly depends on IPv4 address policy.
we do: "distribute numbers to those people that need numbers for their work, in an open, fair, and transparent way".
Fairness includes fairness between people requesting IPv4 address today and tomorrow. Masataka Ohta
participants (5)
-
bmanning＠vacation.karoshi.com -
Gert Doering -
Jeroen Massar -
Masataka Ohta -
trejrco＠gmail.com