Hi All, I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;) The main problem in IPv6 implementation in the real life is a lack of resources. A lot of ISPs (including our company) providing broadband and corporate access to IPv6 Internet. And now it is running globally, pings are pinging, traces are tracing... and so what? The main question users ask us "and so, what we can do with that new IPv6 Internet?". The answer is NOTHING! There is almost NO RESOURCES in IPv6 net! No sites, no pages, no freemails - NOTHING! This makes IPv6 Internet absolutely USELESS for users. Really, unlike us, they do not become happy running bgpd and traceroute6. They need web resources. So why do you think all they change their common network to absolutely useless thing for them after IPv4 will run out? Let's go forward. Yes, a few hosters I know are big companies, LIRs, trade their traffic and so on. But majority are small companines have from one server to one-two racks of hosting servers. They will never become a LIR only for [useless now] IPv6 address space. But they host a huge piece of resources need by a lot of regular users. Yes, IPv6 can provide hosting users a lot of good things, such as unique IP for every site, FTP/SSL/SMB/torrent/personal IP-based ACLs/... without extra costs and so on - this sure will stimulate them to move to IPv6. Yes, some of hosters are ready to obtain IPv6 network and play with it right now. And NO, most of them don't want to use upstream's networks, as there is almost impossible to change it after hundred of thousands of domains are linked with this network. So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On 22 Dec 2009, at 11:14, Max Tulyev wrote:
So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment.
Max, I'm not sure this would result in anything useful. It might even be harmful by encouraging or facilitating route de-aggregation. You are quite right to note the chicken-and-egg problems IPv6 faces and the reasons why IPv6 deployment has been slow. However these factors still exist no matter how an organisation gets its IPv6 space. For instance most content providers don't offer stuff over IPv6 because there are very few people using IPv6. So, in general, from their perspective there's a small audience for v6 content that doesn't justify the costs of providing it. That isn't likely to change even if the content providers got v6 space "for free". I doubt address allocation policies are having an impact on IPv6 deployment or uptake. IMO the drivers for that have still to emerge: like the lack of v4 space (or its price compared to v6) or the operational pain of even more NAT and ALGs.
On 22 dec 2009, at 13:08, Jim Reid wrote:
On 22 Dec 2009, at 11:14, Max Tulyev wrote:
So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment.
Max, I'm not sure this would result in anything useful. It might even be harmful by encouraging or facilitating route de-aggregation.
You are quite right to note the chicken-and-egg problems IPv6 faces and the reasons why IPv6 deployment has been slow. However these factors still exist no matter how an organisation gets its IPv6 space. For instance most content providers don't offer stuff over IPv6 because there are very few people using IPv6. So, in general, from their perspective there's a small audience for v6 content that doesn't justify the costs of providing it. That isn't likely to change even if the content providers got v6 space "for free".
I doubt address allocation policies are having an impact on IPv6 deployment or uptake. IMO the drivers for that have still to emerge: like the lack of v4 space (or its price compared to v6) or the operational pain of even more NAT and ALGs.
I can't agree more, hopefully LTE will become some form of IPv6 killer app but at the moment indeed AP is not the problem causing the lack in IPv6 deployment. MarcoH
Jim Reid wrote:
I doubt address allocation policies are having an impact on IPv6 deployment or uptake. IMO the drivers for that have still to emerge: like the lack of v4 space (or its price compared to v6) or the operational pain of even more NAT and ALGs.
For me and companies around us, there IS a a difference. First is the cost (direct cost and cost of pain with abroad contracts) for just playing with something. This cost will not be returned back, and there is still the financial crisis. Some of our existing hosting customers asked us for IPv6. And they say be never deploy IPv6 just because of direct and indirect costs needs to be payed to RIPE NCC. But wanted to do that before. Users can demand IPv6 from their ISPs to access to some sites. But I don't believe right now users can demand IPv6 visibility from any web site. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;)
Where did you hear this? I just looked at section 8 of RIPE-472 and there is nothing mentioned there.
Yes, a few hosters I know are big companies, LIRs, trade their traffic and so on. But majority are small companines have from one server to one-two racks of hosting servers. They will never become a LIR only for [useless now] IPv6 address space. But they host a huge piece of resources need by a lot of regular users.
Yes, this is true.
So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment.
I don't see any problem with IPv6 PI and I don't understand what you want to change. Please tell us which document to change, and provide a suggestion for the new words to put in the document. --Michael Dillon
michael.dillon@bt.com wrote:
I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;)
Where did you hear this? I just looked at section 8 of RIPE-472 and there is nothing mentioned there.
I hear it from colleague told me hear it from hostmaster ;) I can't find this in the policy too. So who is wrong? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi All,
I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;)
The main problem in IPv6 implementation in the real life is a lack of resources. A lot of ISPs (including our company) providing broadband and corporate access to IPv6 Internet. And now it is running globally, pings are pinging, traces are tracing... and so what? The main question users ask us "and so, what we can do with that new IPv6 Internet?".
The answer is NOTHING!
There is almost NO RESOURCES in IPv6 net! No sites, no pages, no freemails - NOTHING!
This makes IPv6 Internet absolutely USELESS for users. Really, unlike us, they do not become happy running bgpd and traceroute6. They need web resources. So why do you think all they change their common network to absolutely useless thing for them after IPv4 will run out?
Let's go forward.
Yes, a few hosters I know are big companies, LIRs, trade their traffic and so on. But majority are small companines have from one server to one-two racks of hosting servers. They will never become a LIR only for [useless now] IPv6 address space. But they host a huge piece of resources need by a lot of regular users.
Yes, IPv6 can provide hosting users a lot of good things, such as unique IP for every site, FTP/SSL/SMB/torrent/personal IP-based ACLs/... without extra costs and so on - this sure will stimulate them to move to IPv6. Yes, some of hosters are ready to obtain IPv6 network and play with it right now. And NO, most of them don't want to use upstream's networks, as there is almost impossible to change it after hundred of thousands of domains are linked with this network.
So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Changing it in a way that it is allowed (as it is technically possible) to use IPv6 PI for co location/dedicated servers/shared hosting/VPS hosting/etc. would be a good point. Currently it is for us a reason not to support it yet. Another reason is that PFsense doesn't support it yet. Mark
Max Tulyev wrote:
I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;)
OK.
The main problem in IPv6 implementation in the real life is a lack of resources.
So, just use IPv4. What is the problem?
So why do you think all they change their common network to absolutely useless thing for them after IPv4 will run out?
Hugh? With port restricted IP, IPv4 address space won't run out.
Let's go forward.
No, you should just stay here at IPv4.
Yes, IPv6 can provide hosting users a lot of good things,
Hugh?
such as unique IP for every site,
A+P without legacy NAT, or end to end NAT, is more than enough.
FTP/SSL/SMB/torrent/personal IP-based ACLs/... without extra costs and so on
A+P without legacy NAT, or end to end NAT, is more than enough.
- this sure will stimulate them to move to IPv6. Yes,
No, not at all.
So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment.
With port restricted IPv4, you can just ignore IPv6 and keep using IPv4 without losing the end to end transparency. So, why do you bother with IPv6? Masataka Ohta
I can say even more: hosters can really use ONLY ONE IPv4 public address for anything they need. This is not a hoster company problem in general. So they do use IPv4 as you say. The problem is IPv6 Internet is still useless. If it will be when IPv4 runs out, the world will NOT be moved to IPv6, but will use NATs, trade the rest of IPv4 blocks and so on. IPv6 will be ignored as working, but useless thing. I repeat my lovely phrase: If a majority (a half) of web resources will be reachable via IPv6 when IPv4 will be finished, then MAY BE will be the migration to IPv6. If not - then it fails. Now I know NONE of resources reachable. Only some single experiments. Masataka Ohta wrote:
Max Tulyev wrote:
I just hear I can't use IPv6 PI network for hosting service. And I want to talk about it ;)
OK.
The main problem in IPv6 implementation in the real life is a lack of resources.
So, just use IPv4. What is the problem?
So why do you think all they change their common network to absolutely useless thing for them after IPv4 will run out?
Hugh? With port restricted IP, IPv4 address space won't run out.
Let's go forward.
No, you should just stay here at IPv4.
Yes, IPv6 can provide hosting users a lot of good things,
Hugh?
such as unique IP for every site,
A+P without legacy NAT, or end to end NAT, is more than enough.
FTP/SSL/SMB/torrent/personal IP-based ACLs/... without extra costs and so on
A+P without legacy NAT, or end to end NAT, is more than enough.
- this sure will stimulate them to move to IPv6. Yes,
No, not at all.
So I think we should ASAP change IPv6 PI policy to let hosting be the issue for IPv6 PI assignment.
With port restricted IPv4, you can just ignore IPv6 and keep using IPv4 without losing the end to end transparency.
So, why do you bother with IPv6?
Masataka Ohta
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
The problem is IPv6 Internet is still useless.
It's not a problem. Use port restricted IPv4.
If it will be when IPv4 runs out, the world will NOT be moved to IPv6, but will use NATs, trade the rest of IPv4 blocks and so on. IPv6 will be ignored as working, but useless thing.
IPv6 will be ignored, because IPv6 is, technically, useless, which has nothing to do with IPv6 address allocation policy. Because IPv4 NAT can be fully transparent end to end, it's fine to use port restricted IPv4 with NAT.
I repeat my lovely phrase: If a majority (a half) of web resources will be reachable via IPv6 when IPv4 will be finished, then MAY BE will be the migration to IPv6. If not - then it fails.
It's impossible because attempts of optional headers, path MTU discovery, stateless autoconfiguration, aggressive introduction of multicast etc. to make IPv6 better than IPv4 have totally failed only to make IPv6 and its operation a lot more complex and a lot less consistent than IPv4. Masataka Ohta
On Fri, Dec 25, 2009 at 12:09 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
IPv6 will be ignored, because IPv6 is, technically, useless, which has nothing to do with IPv6 address allocation policy.
Because IPv4 NAT can be fully transparent end to end, it's fine to use port restricted IPv4 with NAT.
Well, but there are lots of things you can't do with port restricted IPv4 and NAT. For example, run a peer-to-peer program with 1000 simultaneous connections. Run itunes and Google maps on or your computer, your girlfriend's computer, and your phone at the same time. Run proper VOIP and skype call without using third parties, which degrade your call quality if their internet connections drop packets. On the server side, IP address sharing on a large scale means lack of geolocation, and lack of geolocation means no location-aware services. Search for ramen from your hotel room and expect to find places nearby? Who knows, you might find something in Hokkaido. Want to stream a baseball game in San Francisco? You might not be able to, because the licensing for that content requires you not to be in San Jose and your IP address might mostly be in use by people in San Jose. Trying to go to a website? Better hope your IP address neighbors aren't sending it too many queries, because otherwise the website operator might block your IP address for excessive use. Without IPv6, there will be more and more pressure on port space as user numbers continue to grow, so these problems are likely to get worse and worse. What happens then is anybody's guess. Maybe the quality of Internet connections will get worse and worse and you'll need to pay more for a better connection? Maybe the only reliable services will be the services of the ISP you subscribe to, so we'll go back to a walled garden model?
It's impossible because attempts of optional headers, path MTU discovery, stateless autoconfiguration, aggressive introduction of multicast etc. to make IPv6 better than IPv4 have totally failed only to make IPv6 and its operation a lot more complex and a lot less consistent than IPv4.
As someone who has designed and operated IPv6 networks, I can say it's not more complex, it's just different. In some ways it's easier, too: for example, the large address space eliminates allocation problems and allows addressing plans that are much easier to manage. Autoconfiguration is very useful, and so on. But of course, if you already know how IPv4 works and you don't want to learn anything new it will seem complex. As regards it being impossible, I disagree, and so would the hundreds of thousands of users who use Google over IPv6 every day (assuming they knew they were in fact using it).
Lorenzo Colitti wrote:
IPv6 will be ignored, because IPv6 is, technically, useless, which has nothing to do with IPv6 address allocation policy.
Because IPv4 NAT can be fully transparent end to end, it's fine to use port restricted IPv4 with NAT.
Well, but there are lots of things you can't do with port restricted IPv4 and NAT.
FYI, I'm not talking about A+P, which is a combination of port restricted IP and poor legacy NAT with no end to end transparency. I'm talking about port restricted IP with full end to end transparency for all the applications including skype. See <draft-ohta-e2e-nat-00.txt> how all the applications, including ftp port command and skype, works as is. An implementation is already running.
For example, run a peer-to-peer program with 1000 simultaneous connections.
As a transport connection is identified by both source and destinaiton port numbers, you only need a single port to have 1000 simultaneous connections with 1000 other hosts.
Run itunes and Google maps on or your computer, your girlfriend's computer, and your phone at the same time.
It's trivially easy. Problems caused by improperly behaving applications should be solved by the improperly behaving applications. That's all.
On the server side, IP address sharing on a large scale means lack of geolocation, and lack of geolocation means no location-aware services.
If you want to destroy location privacy, you should better forbid ISPs use PPPoE, which destroys detailed geolocation already today. As there will be no port-wise routers at the backbone (there is no routing protocol to support port wise routing), hosts sharing an IP address are assured to be confined in small geographical area, unless you do yet another tunneling such as PPPoE.
Better hope your IP address neighbors aren't sending it too many queries, because otherwise the website operator might block your IP address for excessive use.
That's no different from the situation today with DHCP assigned /24 or /16 shared by you and your neighbours. Still, it is a lot better than using IPv6, with which you can hardly reach any web site.
Without IPv6, there will be more and more pressure on port space as user numbers continue to grow, so these problems are likely to get worse and worse.
So far, there is no problem of port restricted IP exist.
As someone who has designed and operated IPv6 networks, I can say it's not more complex,
You shouldn't
But of course, if you already know how IPv4 works and you don't want to learn anything new it will seem complex.
As a person who changed IPv6 address structure from 10+6 to 8+8, trying to make IPv6 a little better than the worst, I know very well how IPv6 fails to work. If you don't want to learn anything new from your experience, it's your problem. Masataka Ohta
On Fri, Dec 25, 2009 at 5:52 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
If you don't want to learn anything new from your experience, it's your problem.
Ah, of course, I understand now - it's my problem. Funny I didn't think of that :-) But it occurs to me that an address policy mailing list is not the right place to have a discussion on whether or not IPv6 makes sense. Apologies to the others on this list for following off-topic. I'll stop now. Regards, Lorenzo
Le 25 déc. 2009 à 05:52, Masataka Ohta wrote :
As a person who changed IPv6 address structure from 10+6 to 8+8, trying to make IPv6 a little better than the worst, I know very well how IPv6 fails to work.
Not being such a person, I would be interested in learning in what "IPv6 fails", as you say. (Just stating that IPv6 doesn't help to solve problems!) Can you, please, provide a list of failures you identify for native IPv6 where it is available in addition to IPv4 (leaving out Teredo, 6to4 and ISATAP, which are not IPv6 per se). References to written material would be appreciated. I didn't work on 10+6 and 8+8, but my experience is that of a daily user of native IPv6. As such, I reach in IPv6 various Google and IETF servers, which I use intensively, without having done anything special. (I just enabled IPv6 in my OS which doesn't have IPv6 active by default). Servers that advertise only IPv4 addresses are reached in IPv4 as from anywhere. Note that if more and more hosts would have native IPv6 (in addition to IPv4), and more and more servers would advertise IPv6 addresses (in addition to IPv4), then: o less and less traffic would be IPv4 o NATs (still present for legacy hosts servers and/or service providers) would be less and less used and thus avoid port shortages o peer-to-peer applications would work better where IPv4 is available only through cascades of NATs. Regards, RD
Remi Despres wrote:
As a person who changed IPv6 address structure from 10+6 to 8+8, trying to make IPv6 a little better than the worst, I know very well how IPv6 fails to work.
Not being such a person, I would be interested in learning in what "IPv6 fails", as you say. (Just stating that IPv6 doesn't help to solve problems!) Can you, please, provide a list of failures you identify for native IPv6 where it is available in addition to IPv4 (leaving out Teredo, 6to4 and ISATAP, which are not IPv6 per se).
Though there are so many failures of IPv6, an example suitable for discussion here is a failure to aggregate routes.
References to written material would be appreciated.
IPv6 address allocation policies are the written material. Never say there are ongoing effort to solve the problem, as I know similar efforts have failed several times, already. Another example is a problem of transport payload size. Please simply answer the following question: With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation? Note that IPv6 optional headers can be indefinitely long. Note also that DNS (plain ones without DNSSEC) requires 512B must be carried over UDP.
o peer-to-peer applications would work better where IPv4 is available only through cascades of NATs.
I'm afraid you mean "better than" and peer-to-peer applications have difficulties to run over NAT, especially cascaded NAT, which is not the case with end to end NAT. Masataka Ohta
Masataka, Thanks for your answer. Comments below. Le 5 janv. 2010 à 09:35, Masataka Ohta a écrit :
Remi Despres wrote:
As a person who changed IPv6 address structure from 10+6 to 8+8, trying to make IPv6 a little better than the worst, I know very well how IPv6 fails to work.
Not being such a person, I would be interested in learning in what "IPv6 fails", as you say. (Just stating that IPv6 doesn't help to solve problems!) Can you, please, provide a list of failures you identify for native IPv6 where it is available in addition to IPv4 (leaving out Teredo, 6to4 and ISATAP, which are not IPv6 per se).
Though there are so many failures of IPv6, an example suitable for discussion here is a failure to aggregate routes.
Avoiding the need for provider independent prefixes is an important goal, but IPv4 misses this goal too. Note, besides, that the work I started on SAM (stateless map-and-encaps for simplified mesh-softwire topologies) is precisely expected to lead to a solution in IPv6. (Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01 are planned to be replaced by a better successor for IETF77).
References to written material would be appreciated.
IPv6 address allocation policies are the written material.
Never say there are ongoing effort to solve the problem, as I know similar efforts have failed several times, already.
I agree that IPv6 address allocation policies still need evolution. But I also believe that router and host IPv6 behaviors should be complemented for these policies to fully take advantage of the IPv6 potential concerning multihoming and renumbering.
Another example is a problem of transport payload size. Please simply answer the following question:
With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation?
Since fragmentation is in IPv6 an end-to-end function, I don't see why it would be important to have a fixed value for this number. (A sender that needs no IPv6 option may send without fragmentation more payload bytes than another that needs some options, e.g. for IPsec. Why would this be a problem?)
Note that IPv6 optional headers can be indefinitely long.
The format indeed permits it. Having formats that don't limit lengths is good to have, but doesn't imply that there exists no practical limit. In practice today, the fragmentation option having to be in the first packet (limited to 1280B if nothing better is guaranteed), and the length of options that follow being limited even for sophisticated uses (IPsec or mobility), there is AFAIK such a practical limit today.
Note also that DNS (plain ones without DNSSEC) requires 512B must be carried over UDP.
No problem in IPv6, even if, due to a non typical number of options, datagrams would need to be fragmented.
o peer-to-peer applications would work better where IPv4 is available only through cascades of NATs.
I'm afraid you mean "better than" and peer-to-peer applications have difficulties to run over NAT, especially cascaded NAT, which is not the case with end to end NAT.
I meant that in IPv6 P2P always works, while in IPv4 it works only with limitations if via NATs. End to end NAT is in my understanding a proposal that eliminates these limitations if added to the current IPv4. But these limitations can also be eliminated by using IPv6. This works already where providers, like Free in France, offer native IPv6 in addition to NATed IPv4. IMHO, it would be useful at this stage to list IPv6 functions that can be used safely and usefully. This could result in the definition of an *IPv6 basic-user profile*. Regards, RD
Remi Despres wrote:
Though there are so many failures of IPv6, an example suitable for discussion here is a failure to aggregate routes.
Avoiding the need for provider independent prefixes is an important goal, but IPv4 misses this goal too.
Note, besides, that the work I started on SAM (stateless map-and-encaps
FYI, the architecturally correct solution, which is applicable both to IPv4 and IPv6, was given in draft-ohta-e2e-multihoming-00.txt issued on April 2000.
(Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01 are planned to be replaced by a better successor for IETF77).
FYI, selection of the proper address requires the concept of time out, which does not exist in connectionless IP layer, which means the problem must be solved in transport layer (TCP) or above (applications over UDP). NAT-like approaches to solve the problem at the IP layer are all broken.
I agree that IPv6 address allocation policies still need evolution.
With 4B or 6B port numbers, the problem can be solved as address/port allocation polices of port restricted IPv4.
But I also believe that router and host IPv6 behaviors should
Another example is a problem of transport payload size. Please simply answer the following question:
With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation?
Since fragmentation is in IPv6 an end-to-end function, I don't see why it would be important to have a fixed value for this number.
There is a reason why ISPs must filter ICMPs against fragmentation errors. What, do you think, will happen if your access and backbone MTU are 1500B and you send 1500B multicast packets to people many of which are using PPPoE? If ISPs filter ICMPs against multicast fragmentation errors, most ISPs will filter all the ICMPs. Worse, even if fragmentation had worked, there can be indefinitely lengthy optional headers *BEFORE* a fragmentation header that you can not even assume fragmentation possible.
(A sender that needs no IPv6 option may send without fragmentation more payload bytes than another that needs some options, e.g. for IPsec. Why would this be a problem?)
Because, optional header is not always under the control of applications, as exemplified by MIPv6 headers.
Having formats that don't limit lengths is good to have, but doesn't imply that there exists no practical limit.
FYI, my proposal to IPv6 WG to limit the length to allow for 512B or 1024B DNS message size was voted down, which means the practical limit, conceived by IPv6 WG, can be as large as or even larger than 1280B.
In practice today, the fragmentation option having to be in the first packet (limited to 1280B if nothing better is guaranteed), and the length of options that follow being limited even for sophisticated uses (IPsec or mobility), there is AFAIK such a practical limit today.
Please simply answer the following question: With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation? If you can't, you may assume some practical upper limit on IPv6 optional header length and standardize it in IETF. Then, you can start deploying modified specification expecting that implementations of it will be widely deployed within the next 20 years.
Note also that DNS (plain ones without DNSSEC) requires 512B must be carried over UDP.
No problem in IPv6, even if, due to a non typical number of options, datagrams would need to be fragmented.
With IPv4, header length of which is at most 60B long, fragmentation is always possible. With IPv6, you can expect nothing.
End to end NAT is in my understanding a proposal that eliminates these limitations if added to the current IPv4.
No, it's not an addition. It's a way to implement NAT, which requires no changes on IPv4 routers in public or private IP networks.
This works already where providers, like Free in France, offer native IPv6 in addition to NATed IPv4.
It's a lot of fun to see ISPs, not knowing how ICMPv6 works against multicast fragmentation errors, say they deploy IPv6.
IMHO, it would be useful at this stage to list IPv6 functions that can be used safely and usefully.
Thanks to indefinitely lengthy optional headers, no applications work safely over IPv6. Masataka Ohta
Le 5 janv. 2010 à 14:00, Masataka Ohta a écrit :
Remi Despres wrote:
Note, besides, that the work I started on SAM (stateless map-and-encaps
FYI, the architecturally correct solution, which is applicable both to IPv4 and IPv6, was given in draft-ohta-e2e-multihoming-00.txt issued on April 2000.
Thanks for the interesting reference. However, talking about THE solution seems to me too much: - The SAM approach (to be soon renamed Mesh-softwire lite - MSL) avoids your requirement that hosts run BGP, and support the full worldwide routing table. - Named based extensions of socket APIs seem IMHO to have more potential than multiple address APIs.
(Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01 are planned to be replaced by a better successor for IETF77).
FYI, selection of the proper address requires the concept of time out, which does not exist in connectionless IP layer, which means the problem must be solved in transport layer (TCP) or above (applications over UDP).
It is clear that UDP is adequate only if E2E paths are not too frequently broken, and if broken connections are acceptable if they are rare. To change connection addresses on the fly, if needed to avoid breaking connection when E2E paths break, using DCCP in place of UDP seems a natural approach (and using SCTP, Shim6, or Multipath TCP, in place of TCP).
NAT-like approaches to solve the problem at the IP layer are all broken.
Agreed. But note that the SAM-MSL approach is not in this category.
I agree that IPv6 address allocation policies still need evolution.
With 4B or 6B port numbers, the problem can be solved as address/port allocation polices of port restricted IPv4.
Such a drastic evolution, only justified to avoid IPv6, would be unreasonable. (IPv6 is available in router and host products, and successfully deployed in some subsets of the Internet.)
Another example is a problem of transport payload size. Please simply answer the following question:
With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation?
Since fragmentation is in IPv6 an end-to-end function, I don't see why it would be important to have a fixed value for this number.
There is a reason why ISPs must filter ICMPs against fragmentation errors. What, do you think, will happen if your access and backbone MTU are 1500B and you send 1500B multicast packets to people many of which are using PPPoE? If ISPs filter ICMPs against multicast fragmentation errors, most ISPs will filter all the ICMPs.
In IPv6, fragmentation errors being an end-to-end matter, ISPs that don't support IPv6 multicast themselves are not concerned. E2E fragmentation is IMHO one of the significant pluses of IPv6.
Worse, even if fragmentation had worked, there can be indefinitely lengthy optional headers *BEFORE* a fragmentation header that you can not even assume fragmentation possible.
(A sender that needs no IPv6 option may send without fragmentation more payload bytes than another that needs some options, e.g. for IPsec. Why would this be a problem?)
Because, optional header is not always under the control of applications, as exemplified by MIPv6 headers.
Applications are and must remain unaware of whether their datagrams are transmitted in single or multiple fragments.
Having formats that don't limit lengths is good to have, but doesn't imply that there exists no practical limit.
FYI, my proposal to IPv6 WG to limit the length to allow for 512B or 1024B DNS message size was voted down, which means the practical limit, conceived by IPv6 WG, can be as large as or even larger than 1280B. ` The IP layer introduces per se no constraint on DNS-message lengths. This is not an IP layer issue.
In practice today, the fragmentation option having to be in the first packet (limited to 1280B if nothing better is guaranteed), and the length of options that follow being limited even for sophisticated uses (IPsec or mobility), there is AFAIK such a practical limit today.
Please simply answer the following question:
With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation?
If you can't, you may assume some practical upper limit on IPv6 optional header length and standardize it in IETF. Then, you can start deploying modified specification expecting that implementations of it will be widely deployed within the next 20 years.
Native IPv6 is deployed today and, for its users, works fine for a number of applications (without harm to other applications that use IPv4 as before). I don't understand this point about needing to wait.
Note also that DNS (plain ones without DNSSEC) requires 512B must be carried over UDP.
No problem in IPv6, even if, due to a non typical number of options, datagrams would need to be fragmented.
With IPv4, header length of which is at most 60B long, fragmentation is always possible. With IPv6, you can expect nothing.
I don't understand what you mean.
End to end NAT is in my understanding a proposal that eliminates these limitations if added to the current IPv4.
No, it's not an addition. It's a way to implement NAT, which requires no changes on IPv4 routers in public or private IP networks.
To me, extending the specification of IPv4 NATs and of IPv4-capable hosts is a modification of the IPv4 protocol suite. But this is just a vocabulary question. The important fact is that existing products generally support IPv6 basic functions, and generally AFAIK don't support E2E-NAT.
This works already where providers, like Free in France, offer native IPv6 in addition to NATed IPv4.
It's a lot of fun to see ISPs, not knowing how ICMPv6 works against multicast fragmentation errors, say they deploy IPv6.
It's not that they "say" to have deployed it: their customers, of which I am, actually use it. The fact that they don't support multicast can be reason why their IPv6 service works nicely. (But note that they don't support multicast in IPv4 either.) I am not familiar enough with this issue to discuss it more. A good reference about it would be appreciated.
IMHO, it would be useful at this stage to list IPv6 functions that can be used safely and usefully.
Thanks to indefinitely lengthy optional headers, no applications work safely over IPv6.
This statement seems to me completely ideological! There exists today, and in the real world, applications that DO WORK safely over IPv6. Are you ignoring it? Or willing to deny it? If a host has a native IPv6 address, its real world OS (Windows, OS X, Linux etc) does not add options that might create problems. (AFAIK, the only option used is for fragmentation.) It's time, IMHO, to avoid fighting the lost battle against IPv6 being deployed and used. RD
Remi Despres wrote: In this mail, I assume readers have read the original paper on the end to end principle by Saltzer et. al. and understand the implications of "completely and correctly" mentioned in the paper.
However, talking about THE solution seems to me too much: - The SAM approach (to be soon renamed Mesh-softwire lite - MSL) avoids your requirement that hosts run BGP,
As is discussed in my ID, BGP is not my requirement.
and support the full worldwide routing table.
That is not my requirement, either, though small full routing table helps to guess the best address to try.
- Named based extensions of socket APIs seem IMHO to have more potential than multiple address APIs.
As was proven in my previous mail, as IP layer (hostnames belongs to IP layer) is connectionless and does not support notion of time out, proposals not involving transport layer of end systems are broken. They must, like legacy NAT, guess transport layer time out. The guesses, not using "knowledge and help" of end systems, are not done "completely and correctly" as is discussed in the original end to end paper of Saltzer et. al.
It is clear that UDP is adequate only if E2E paths are not too frequently broken, and if broken connections are acceptable if they are rare.
Connection? UDP, in general, is connectionless and applications like vanilla DNS works with request and reply without establishing connection, at least not TCP-like connection. Still, note that RFC1035 requires DNS implement end to end multihoming.
To change connection addresses on the fly,
If you think DNS an important application, never say connection.
NAT-like approaches to solve the problem at the IP layer are all broken.
But note that the SAM-MSL approach is not in this category.
Anything relying on incorrect and incomplete guesses on route failure is NAT-like and violates the end to end principle.
With 4B or 6B port numbers, the problem can be solved as address/port allocation polices of port restricted IPv4.
Such a drastic evolution, only justified to avoid IPv6, would be unreasonable.
As changes required to support IPv6 is a lot more drastic, you successfully deny IPv6.
In IPv6, fragmentation errors being an end-to-end matter,
In IPv6, fragmentation is end to end. However, as fragmentation errors are generated by intermediate routers, fragmentation handling of IPv6 is not at all end to end. As such, path MTUs guessed by end hosts are "incomplete and incorrect", which is why path MTU discovery performs poorly violating the end to end principle. For example, end hosts can not directly know path MTU increase, which is "incomplete and incorrect".
ISPs that don't support IPv6 multicast themselves are not concerned.
The ISPs must filter fragmentation errors, to protect their customers from ICMP implosion caused by 1500B multicast packets sent from other ISPs with forged source addresses.
E2E fragmentation is IMHO one of the significant pluses of IPv6.
E2E fragmentation relies on PMTUD. If only PMTUD, which is not end to end, had worked.
Applications are and must remain unaware of whether their datagrams are transmitted in single or multiple fragments.
Applications over UDP like DNS should be aware, just as TCP is aware. `
The IP layer introduces per se no constraint on DNS-message lengths.
Please simply answer the following question: With 1280B of path MTU, how many bytes, do you think, are assured to be carried over UDP over IPv6 without fragmentation?
Native IPv6 is deployed today and, for its users, works fine for a number of applications (without harm to other applications that use IPv4 as before).
Then, you should be able to answer the question above. Please.
With IPv4, header length of which is at most 60B long, fragmentation is always possible. With IPv6, you can expect nothing.
I don't understand what you mean.
Read RFC791, how well IPv4 is designed with its fragmentation.
To me, extending the specification of IPv4 NATs and of IPv4-capable hosts is a modification of the IPv4 protocol suite.
That's not a useful definition.
The important fact is that existing products generally support IPv6 basic functions, and generally AFAIK don't support E2E-NAT.
That's not an important fact that port restricted IP, including but not limited to E2E NAT, is not supported by most equipment, because port restricted IP can be deployed locally and still interact with the rest of the world. On the other hand, IPv6 deployment requires IPv6 deployment at the network and at both ends, which is, as you can see even 15 years after RFC1883, impossible.
The fact that they don't support multicast can be reason why their IPv6 service works nicely.
See above for a possible ICMP implosion DOS attack.
I am not familiar enough with this issue to discuss it more. A good reference about it would be appreciated.
RFC2463 (ICMPv6 spec.).
Thanks to indefinitely lengthy optional headers, no applications work safely over IPv6.
This statement seems to me completely ideological!
Then, try to answer my simple question above.
There exists today, and in the real world, applications that DO WORK safely over IPv6.
People working on DNSSEC seriously (though DNSSEC is bogus) want to know how long messages can be safely sent over UDP over IPv6. Your answer to my question will be quite helpful for them.
Are you ignoring it? Or willing to deny it?
I'm afraid you have been ignoring UDP and DNS, which are my examples to deny IPv6.
If a host has a native IPv6 address, its real world OS (Windows, OS X, Linux etc) does not add options that might create problems. (AFAIK, the only option used is for fragmentation.)
As I already mentioned, optional headers are added with MIPv6.
It's time, IMHO, to avoid fighting the lost battle against IPv6 being deployed and used.
IPv6 was wrongly specified, vigorously implemented, partially deployed, partially used and totally failed, partly because of broken specification. That's all. Masataka Ohta
On 5 Jan 2010, at 17:56, Masataka Ohta wrote:
As is discussed in my ID, BGP is not my requirement.
Can this discussion take place somewhere else? It does not now have anything relevant or appropriate for this list.
Hi, Max. On 22 Dec 2009, at 11:14, Max Tulyev wrote:
I just hear I can't use IPv6 PI network for hosting service.
Yes you can. Hi, Mark. On 22 Dec 2009, at 12:58, Mark Scholten wrote:
Changing it in a way that it is allowed (as it is technically possible) to use IPv6 PI for co location/dedicated servers/shared hosting/VPS hosting/etc. would be a good point.
You can do this. Best wishes, Andy
participants (9)
-
Andy Davidson -
Jim Reid -
Lorenzo Colitti -
Marco Hogewoning -
Mark Scholten -
Masataka Ohta -
Max Tulyev -
michael.dillon＠bt.com -
Rémi Després