Re: 6to4 damages the Internet (was Re:
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: Moreover, unlike nat64, nat44 can be fully transparent end to end. Some people may consider it a feature that only incumbents with power and money can usefully call listen(), and that useful user to user activities requires the cooperation of an intrusive 3rd party, while mere users and upstarts can only call connect(). Some people consider that a feature. I do not. It is, in fact, getting really hard to avoid assuming malice on the part of people who want to nail the world to the nat44 cross. .. Mark Atwood ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
Mark Atwood wrote: Moreover, unlike nat64, nat44 can be fully transparent end to end. Some people may consider it a feature that only incumbents with power and money can usefully call listen(), and that useful user to user activities requires the cooperation of an intrusive 3rd party, while mere users and upstarts can only call connect(). It is, in fact, getting really hard to avoid assuming malice on the part of people who want to nail the world to the nat44 cross. Isn't port forwarding over legacy nat44 enough for you? For me, port forwarding is not enough because it lacks end to end transparency. For example, you can't use PORT command of your ftp client behind legacy nat. See draft-ohta-e2e-nat-00.txt for how nat44 can be transparent end to end. OTOH, nat64 can not have end to end transparency. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
In your letter dated Thu, 28 Jul 2011 18:55:04 -0700 you wrote: On Jul 28, 2011 5:28 PM, Martin Rex m...@sap.com wrote: It would be so much easier if hosts on the public internet could use one single IPv6 address that contains both, the IPv6 network prefix and the IPv4 host address, and then let the network figure out whether the connect goes through as IPv4 or IPv6 (for IPv6 clients). In particular, if the remote address is encoded this way. If the host has to chose between an IPv6 or IPv4 destination address then the protocol is fixed. I think that would have been a much better use of thse bits then simply storing the ethernet address there. But anyhow, it should be possible to do that with a destination option with is then inspected by some middle box that makes a routing decision. But that would require a lot of changes to retrofit it in todays operating systems. This is largely (not entirely) achieved with nat64 / dns64. That would require the dns64 box to do destination selection. Possible, but maybe also tricky to keep a dns resolver informed about the current state of the network. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
Philip Homburg wrote: I think that would have been a much better use of thse bits then simply storing the ethernet address there. IPv6 address was (when it was SIP) and should be 8B, but extended to be 16B to store ethernet address with wrong reasoning of RFC1715 only to make IPv6 inoperational. At that time, it was 10B+6B, but as I pointed it out that IEEE1394 MAC is 8B long, it became 8B+8B. But anyhow, it should be possible to do that with a destination option with is then inspected by some middle box that makes a routing decision. But that would require a lot of changes to retrofit it in todays operating systems. That's no different from legacy NAT to violate the end to end principle. For example, just as legacy NAT, transport check sum depends on actually used address family and address. Thus, transport check sum must be recalculated by the middle box which changes address family. That would require the dns64 box to do destination selection. Possible, but maybe also tricky to keep a dns resolver informed about the current state of the network. That's guaranteed to be impossible by the end to end argument: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. Destination address selection is the function in question and complete and correct implementation by middle boxes is just impossible. The only approach for the address selection function is to do it at the end systems using knowledge and help of the end systems, which requires end systems have knowledge on default free global routing tables. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote: PS - And in those cases, proper address selection is a much better solution (IMHO) than hitting this screw with a hammer. I think the problem is that we don't know how to do 'proper' address selection. It would be nice if 5 or 10 years ago there would have been a good standard to do address selection. Today, we are just in the stage of doing more experiments. There is one thing that works well. And that is, you only assign global IPv6 addresses to a host if global IPv6 connectivity is at least as good as IPv4 connectivity. We want large scale deployment of IPv6 today not some time in the future when we finally figured out address selection. And that means that today we have to make sure that users don't end up with unreliable IPv6 connections. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
Philip Homburg wrote: I think the problem is that we don't know how to do 'proper' address selection. I know and it's trivially easy. It would be nice if 5 or 10 years ago there would have been a good standard to do address selection. 11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote: End systems (hosts) are end systems. To make the end to end principle effectively work, the end systems must have all the available knowledge to make decisions by the end systems themselves. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. which means an end system should have a full routing table, IGP metrics in which tell the end system what is the best address of its multihomed peer. Full routing table should and can, of course, be small. The approach is totally against node/router separation of IPv6 to make routers, the intermediate systems, a lot more intelligent than nodes, the end systems, which is partly why IPv6 is hopeless. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
On Jul 28, 2011, at 3:50 AM, Philip Homburg wrote: In your letter dated Wed, 27 Jul 2011 23:41:38 -0400 you wrote: PS - And in those cases, proper address selection is a much better solution (IMHO) than hitting this screw with a hammer. I think the problem is that we don't know how to do 'proper' address selection. It would be nice if 5 or 10 years ago there would have been a good standard to do address selection. Today, we are just in the stage of doing more experiments. There is one thing that works well. And that is, you only assign global IPv6 addresses to a host if global IPv6 connectivity is at least as good as IPv4 connectivity. In general, all of a host's addresses (at least, those in the same preference class in the address selection algorithm) need to work equally well from everywhere. But even that might not be sufficient. Fred Baker has recently been citing a different example of the same problem: Imagine a future where hosts on a network have both v6 and legacy v4 through stateful NAT. Because the v6 connection works well most of the time, hosts tend to choose v6 destinations, and sites reduce the capacity of their NATs over time. Then the v6 connection fails, and suddenly everything falls back to v4, and the connections through NAT also fail for lack of sufficient capacity to handle the load. Note that in some sense this is a perceptual problem. If instead of a v4 and a v6 address, each of those hosts had two v6 addresses and two different egress paths, the network engineers would be more likely to understand that both external connections needed to be of equal capacity - just like multihomed v4 networks with a single prefix now. And in some sense there's nothing wrong with having a v6 connection for most things and a small v4 NAT for connecting to legacy v4 services, as long as you don't think of the v4 path as a fallback - you're willing to accept that loss of the v6 connection is for practical purposes loss of external connectivity. The problem is that if you think of the v4 NAT as a fallback for the v6 service, AND you don't drastically overprovision the NAT. We want large scale deployment of IPv6 today not some time in the future when we finally figured out address selection. And that means that today we have to make sure that users don't end up with unreliable IPv6 connections. If you make the constraint that nobody can use IPv6 at all until the IPv6 connections work as well in all cases as the IPv4 connections, that creates a huge barrier to the universal deployment of IPv6 - which already has enough barriers as it is. A less onerous constraint is that less reliable IPv6 connections don't get used in preference to more reliable IPv4 connections. We're lucky in the case of 6to4 in that it has a well-known prefix that allows the traffic to be distinguished from other v6 traffic. But it's still necessary to manage expectations about IPv4 as a fallback path. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
In your letter dated Thu, 28 Jul 2011 07:50:38 -0400 you wrote: In general, all of a host's addresses (at least, those in the same preference class in the address selection algorithm) need to work equally well from everywhere. But even that might not be sufficient. Fred Baker has recently been citing a different example of the same problem: Imagine a future where hosts on a network have both v6 and legacy v4 through stateful NAT. Because the v6 connection works well most of the time, hosts tend to choose v6 destinations, and sites reduce the capacity of their NATs over time. Then the v6 connection fails, and suddenly everything falls back to v4, and the connections through NAT also fail for lack of sufficient capacity to handle the load. I'm sure some manager will just require this to work. But I would say that this is just supposed to fail. If you had in the past just an IPv4 connection and it went down, there would be no Internet access. Same thing in the future. If your IPv6 connection goes down you don't have an Internet conenction. It would be different if the NAT was there just to connect to a very specific collection of legacy IPv4 sites. But that can be solved easily but just routing those IPv4 prefixes to the NAT. If you want the NAT to provide full redundancy, then it has to be scaled to accept full load. Otherwise, no IPv6 just means no Internet. Very simple. We want large scale deployment of IPv6 today not some time in the future when we finally figured out address selection. And that means that today we have to make sure that users don't end up with unreliable IPv6 connections. If you make the constraint that nobody can use IPv6 at all until the IPv6 connections work as well in all cases as the IPv4 connections, that creates a huge barrier to the universal deployment of IPv6 - which already has enough barriers as it is. To some extent that is exactly the way it is. Suppose that a significant fraction of popular websites would have IPv6 addresses that don't actually work. Then essentially no ISP would enable IPv6 for their customers because their customers would suffer. At the moment, most servers that do have IPv6 addresses seem to actually support IPv6 so this doesn't seem to be a big problem. But we don't know what the future might bring. If there would be a sudden rush of servers that have PMTU problems, then we could have a very serious problem. A less onerous constraint is that less reliable IPv6 connections don't get used in preference to more reliable IPv4 connections. We're lucky in the case of 6to4 in that it has a well-known prefix that allows the traffic to be distinguished from other v6 traffic. But it's still necessary to manage expectations about IPv4 as a fallback path. Happy Eyeballs can solve a lot of problems where a connection will fail completely or have a high latency. But HE support is far from universal and so far experience is limited to TCP. But it doesn't do anything for PMTU problems. It also doesn't do anything for real-time streaming applications. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
In your letter dated Thu, 28 Jul 2011 17:08:01 +0900 you wrote: Philip Homburg wrote: I think the problem is that we don't know how to do 'proper' address selection. I know and it's trivially easy. 11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote: End systems (hosts) are end systems. To make the end to end principle effectively work, the end systems must have all the available knowledge to make decisions by the end systems themselves. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. which means an end system should have a full routing table, IGP metrics in which tell the end system what is the best address of its multihomed peer. Full routing table should and can, of course, be small. Even in the unlikely case that it would be feasible to give every host a complete copy of the DFZ routing table... That still would leave a lot of issues open... 1) End-to-end latency. Maybe some future generation BGP provides that, but that doesn't help now. 2) For 6to4, the use of anycase. You probably need a link-state routing protocol to allow a host to figure out which relays are going to be used on a give path. 3) Filters in firewalls. I'd love to see a routing protocol that reports the settings of all firewalls in the world :-) 4) Other performance metrics, like jitter, packets loss, etc. Maybe you can do some experiments and report on how well your draft works for deciding when to prefer a 6to4 address over IPv4. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
Philip Homburg wrote: which means an end system should have a full routing table, IGP metrics in which tell the end system what is the best address of its multihomed peer. Full routing table should and can, of course, be small. Even in the unlikely case that it would be feasible to give every host a complete copy of the DFZ routing table... With RFC2374, DFZ of IPv6 has at most 8192 entries. That still would leave a lot of issues open... 1) End-to-end latency. Maybe some future generation BGP provides that, but that doesn't help now. Your requirement can be fair, only with a routing protocol supporting latency based routing for *an* address with *multiple* paths to its destination. There is no point to have a latency based selection of multiple paths to the destination, only if the destination has multiple addresses. 2) For 6to4, the use of anycase. You probably need a link-state routing protocol to allow a host to figure out which relays are going to be used on a give path. With anycast, you can use only a single relay. Instead, you can compare metrics between IPv4 and IPv6 addresses of a host. 3) Filters in firewalls. I'd love to see a routing protocol that reports the settings of all firewalls in the world :-) Are you saying filtering of firewalls can be disabled by proper address selection? 4) Other performance metrics, like jitter, packets loss, etc. See 1). Maybe you can do some experiments and report on how well your draft works for deciding when to prefer a 6to4 address over IPv4. A problem is that there is no point to stick to IPv6 broken so much. But, it's not my problem. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
Masataka Ohta wrote: It would be nice if 5 or 10 years ago there would have been a good standard to do address selection. 11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote: End systems (hosts) are end systems. To make the end to end principle effectively work, the end systems must have all the available knowledge to make decisions by the end systems themselves. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. The primary reason why the IPv4 - IPv6 transition is so painful is that it requires everyone one and everything to become multi-homed and every software to perform multi-connect, even though most devices actually just have a single interface. It would be so much easier if hosts on the public internet could use one single IPv6 address that contains both, the IPv6 network prefix and the IPv4 host address, and then let the network figure out whether the connect goes through as IPv4 or IPv6 (for IPv6 clients). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
On Jul 28, 2011 5:28 PM, Martin Rex m...@sap.com wrote: Masataka Ohta wrote: It would be nice if 5 or 10 years ago there would have been a good standard to do address selection. 11 years ago in draft-ohta-e2e-multihoming-00.txt, I wrote: End systems (hosts) are end systems. To make the end to end principle effectively work, the end systems must have all the available knowledge to make decisions by the end systems themselves. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. The primary reason why the IPv4 - IPv6 transition is so painful is that it requires everyone one and everything to become multi-homed and every software to perform multi-connect, even though most devices actually just have a single interface. It would be so much easier if hosts on the public internet could use one single IPv6 address that contains both, the IPv6 network prefix and the IPv4 host address, and then let the network figure out whether the connect goes through as IPv4 or IPv6 (for IPv6 clients). This is largely (not entirely) achieved with nat64 / dns64. Cb. -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: 6to4 damages the Internet (was Re:
Cameron Byrne wrote: The primary reason why the IPv4 - IPv6 transition is so painful is that it requires everyone one and everything to become multi-homed and every software to perform multi-connect, even though most devices actually just have a single interface. It was not a problem, because IPv6 was designed to be able to handle multiple addresses properly with a single interface. It would be so much easier if hosts on the public internet could use one single IPv6 address that contains both, the IPv6 network prefix and the IPv4 host address, and then let the network figure out whether the connect goes through as IPv4 or IPv6 (for IPv6 clients). This is largely (not entirely) achieved with nat64 / dns64. Assuming NAT, we don't need IPv6. Moreover, unlike nat64, nat44 can be fully transparent end to end. So, why do we have to be bothered by 6to4? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
On Jul 27, 2011, at 3:32 AM, t.petch wrote: I oppose this action. I see clear evidence that 6to4 is damaging the Internet and although there are those who can use it without causing damage, I believe that the principle is 'First, do no harm' so the IETF has a responsibility to discourage its use. [...] I'd like to address the point that 6to4 damages the Internet. I do understand the content providers' argument - if 6to4 is turned on at the originator's host or network, the destination is advertising both A and records, and the record is chosen in preference to the A record, the user's experience is degraded. Sometimes the performance is degraded marginally (but the cumulative effect of lots of small delays on a web page that loads dozens of images is large). Sometimes it's degraded significantly because the 6to4 address doesn't work at all. Both cases matter, and they do provide a disincentive to content providers to just slap records onto their sites and be done with it. (There are other ways of a web site utilizing v6, but they require more work.) A lot of the arguments that I hear about 6to4 being bad in a universal sense seem to be based on the assumption that it's only access to content in the public Internet that matters. But anyone who has followed IPv6 development should know better than that. If access to content in the public Internet were all that mattered, there would have been no interest in ULAs. It remains the case that many enterprise networks have all kinds of internal resources that are useful to them even if they're not publicly addressable, and are only usable from within that network or from other networks with which they have made explicit arrangements. For better or worse, an explicit design feature of IPv6 is that hosts can have multiple addresses, and that different addresses might be needed in different contexts. A host's public address might be used when contacting a public web server, but when communicating within an enterprise network or between networks each using ULA space, the host might need to use its ULA address as a source address (the other host might not have a public address or the ability to send traffic to the public IPv6 network). I put the word feature in quotes because this can be a pain in the a** for applications and users. The default address selection rules don't really handle this case very well, nor can any set of static default rules handle this case. Essentially what having multiple addresses per host implies is that hosts or applications need to do routing in the absence of routing information. It shouldn't surprise anybody that the use of addresses that only work well (or at all) within a limited scope creates situations where a host will try to send traffic down a path that will never get it there, even when a different path would have worked. Introducing IPv6 - any kind of IPv6 - into a world of hosts that already support IPv4, creates exactly this situation. Nothing in IPv4 prohibited hosts from having multiple addresses and from advertising multiple addresses in DNS.But this feature was rarely used, except in cases where all of the addresses were approximately equivalent in performance, because it didn't work well if some addresses performed better than others. Then, as now, hosts and applications had no good way of reliably choosing which source and destination address to use. But unlike IPv4, IPv6 deliberately chose to not only support the ability to have multiple addresses per host, but to actually expect it in a number of cases. One way to look at the content providers' complaint against 6to4, is that 6to4 addresses are not approximately equivalent in performance to IPv4 addresses. So when hosts or applications happen to choose the 6to4 address over an IPv4 address for the same resource, sometimes that choice ends up not working, or being suboptimal. This is nothing new with 6to4. It's inherently the case that having multiple addresses for a host that aren't equivalent in performance leads to suboptimal choices in some cases. So essentially, the argument that 6to4 damages the Internet, is tantamount to having multiple addresses for hosts damages the Internet. And this is an explicitly chosen architectural feature of IPv6. Blaming 6to4 for the problems caused by this feature is like blaming the canary carried by a coal miner for ceasing to chirp. (Though as it turns out, in the case of 6to4 the fix is relatively easy - just make 6to4 lower preference than either IPv4 or native IPv6 addresses except when the source and destination are both 6to4. ) -- People who are entirely engaged in providing content may have a hard time seeing any utility in 6to4. They may ask, if it doesn't deliver content as well as IPv4 does, what good is it?. My answer to that question is, what good are private networks and ULAs? 6to4 as defined by
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
Keith Moore wrote: I see clear evidence that 6to4 is damaging the Internet and although there are those who can use it without causing damage, I believe that the principle is 'First, do no harm' I put the word feature in quotes because this can be a pain in the a** It means it's IPv6 which is damaging the Internet. Introducing IPv6 - any kind of IPv6 - into a world of hosts that A revised IPv6 and transport which can properly handle multiple addresses can happily coexist with IPv4. However, as IPv6 is totally broken, it is better to start with a clean slate than to revise it. Or, more practically, just stick to IPv4. Nothing in IPv4 prohibited hosts from having multiple addresses IPv4 with revised transport is far better than the current IPv6 and transport. And this is an explicitly chosen architectural feature of IPv6. which is partly why IPv6 is broken and harmful. Proper support of multihoming can be done only at the transport layer and above. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
Thank you Keith for restating the problem. Keith == Keith Moore mo...@network-heretics.com writes: Keith So essentially, the argument that 6to4 damages the Keith Internet, is tantamount to having multiple addresses for Keith hosts damages the Internet. +1 ... Keith People who are entirely engaged in providing content may have Keith a hard time seeing any utility in 6to4. They may ask, if Keith it doesn't deliver content as well as IPv4 does, what good is Keith it?. My answer to that question is, what good are private Keith networks and ULAs? And, we need to remember that the IETF is the stewart of the IP protocol suite, not the stewart of the Internet. Perhaps we actually need Klensin's Internet Standard series, not as a two-level or something else, but as agreement as to what happens on the public Internet, vs what might happen behind closed doors. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
On Wed, Jul 27, 2011 at 14:18, Keith Moore mo...@network-heretics.comwrote: So essentially, the argument that 6to4 damages the Internet, is tantamount to having multiple addresses for hosts damages the Internet. *And this is an explicitly chosen architectural feature of IPv6.* Having multiple addresses for hosts damages the Internet Multiple addresses for hosts damages the Internet - IPv6 damages the Internet I give up. I wish you a productive discussion from here on. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
On Jul 27, 2011, at 2:42 PM, Masataka Ohta wrote: Keith Moore wrote: I see clear evidence that 6to4 is damaging the Internet and although there are those who can use it without causing damage, I believe that the principle is 'First, do no harm' I put the word feature in quotes because this can be a pain in the a** It means it's IPv6 which is damaging the Internet. Except that the (v4) Internet is already doing its best to damage itself. So the choice is between a thoroughly brain-damaged v4 Internet that is continually getting worse, and a somewhat less brain-damaged v6 Internet that has at least some chance of having a few things fixed - though all of the existing successful content and services are optimized for the v4 Internet. But again, fixing the 6to4 version of this problem is relatively easy, and pretty much everybody agrees on mechanisms that will fix the problem. The only disagreement is how to make the message as clear and effective as possible, and there are glimmers of hope in that area. People just shouldn't get lulled into thinking that the problem will go away once 6to4 is fixed. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
Keith Moore wrote: It means it's IPv6 which is damaging the Internet. Except that the (v4) Internet is already doing its best to damage itself. So the choice is between a thoroughly brain-damaged v4 Internet that is continually getting worse, and a somewhat less brain-damaged v6 Internet that has at least some chance of having a few things fixed You are wrong. While IPv4 is demonstratively usable, IPv6 along with ND is too bloated that it is totally unusable. For example, packet too big for multicast PMTUD causes ICMPv6 implosions which may be used for DoS. While IPv4 guarantees that 516B payload receivable by any host, IPv6 can't. Because of indefinitely length header options, some of which (e.g. options for mobility) are inserted without trasnport/application control, there is no room, not even 1B, reserved for payload. And, the worst problem is that 16B address, thanks to poor estimation of RFC1715, is impossible to remember. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
From an operators point of view, specifically one that has deployed 6to4 relays, use of the same should not be encouraged. I fully hope and expect the use of 6to4 to systematically decrease over time so the associated infrastructure can be decommissioned. While we have seen issues related to 6to4 decrease recently the deployment of the same over the years, in particular open relays, has grossly complicated deploying 6to4 in a reliable manner. I have not been able to keep up with all the emails and threads related to this topic, I apologize for this. The bottom line from my point of view is that we (the IETF) should do something to discourage the use of the same. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 7/27/11 2:18 PM, Keith Moore mo...@network-heretics.com wrote: On Jul 27, 2011, at 3:32 AM, t.petch wrote: I oppose this action. I see clear evidence that 6to4 is damaging the Internet and although there are those who can use it without causing damage, I believe that the principle is 'First, do no harm' so the IETF has a responsibility to discourage its use. [...] I'd like to address the point that 6to4 damages the Internet. I do understand the content providers' argument - if 6to4 is turned on at the originator's host or network, the destination is advertising both A and records, and the record is chosen in preference to the A record, the user's experience is degraded. Sometimes the performance is degraded marginally (but the cumulative effect of lots of small delays on a web page that loads dozens of images is large). Sometimes it's degraded significantly because the 6to4 address doesn't work at all. Both cases matter, and they do provide a disincentive to content providers to just slap records onto their sites and be done with it. (There are other ways of a web site utilizing v6, but they require more work.) A lot of the arguments that I hear about 6to4 being bad in a universal sense seem to be based on the assumption that it's only access to content in the public Internet that matters. But anyone who has followed IPv6 development should know better than that. If access to content in the public Internet were all that mattered, there would have been no interest in ULAs. It remains the case that many enterprise networks have all kinds of internal resources that are useful to them even if they're not publicly addressable, and are only usable from within that network or from other networks with which they have made explicit arrangements. For better or worse, an explicit design feature of IPv6 is that hosts can have multiple addresses, and that different addresses might be needed in different contexts. A host's public address might be used when contacting a public web server, but when communicating within an enterprise network or between networks each using ULA space, the host might need to use its ULA address as a source address (the other host might not have a public address or the ability to send traffic to the public IPv6 network). I put the word feature in quotes because this can be a pain in the a** for applications and users. The default address selection rules don't really handle this case very well, nor can any set of static default rules handle this case. Essentially what having multiple addresses per host implies is that hosts or applications need to do routing in the absence of routing information. It shouldn't surprise anybody that the use of addresses that only work well (or at all) within a limited scope creates situations where a host will try to send traffic down a path that will never get it there, even when a different path would have worked. Introducing IPv6 - any kind of IPv6 - into a world of hosts that already support IPv4, creates exactly this situation. Nothing in IPv4 prohibited hosts from having multiple addresses and from advertising multiple addresses in DNS.But this feature was rarely used, except in cases where all of the addresses were approximately equivalent in performance, because it didn't work well if some addresses performed better than others. Then, as now, hosts and applications had no good way of reliably choosing which source and destination address to use. But unlike IPv4, IPv6 deliberately chose to not only support the ability to have multiple addresses per host, but to actually expect it in a number of cases. One way to look at the content providers' complaint against 6to4, is that 6to4 addresses are not approximately equivalent in performance to IPv4 addresses. So when hosts or applications happen to choose the 6to4 address over an IPv4 address for the same resource, sometimes that choice ends up not working, or being suboptimal. This is nothing new with 6to4. It's inherently the case that having multiple addresses
Re: 6to4 damages the Internet (was Re: draft-ietf-v6ops-6to4-to-historic (yet again))
To be fair - I don't think anyone is saying We should totally encourage 6to4!, even in the short-term ... or any other auto-tunneling transition mechanism, really. In fact, I think the debate here largely stems from a valid desire to discourage 6to4. Note: That goal, I am in favor of (recommending that 6to4 be disabled by default on client platforms). However, the proposals on the table seek to reclassify 6to4 as historic - something that has raised a noticeable amount of debate about 1) what historic really means and/or 2) what impact that re-classification may have on currently-functional 6to4 usage today. /TJ ... who wishes to note that 6to4 works *just fine* ... except when it doesn't. PS - And in those cases, proper address selection is a much better solution (IMHO) than hitting this screw with a hammer. On Wed, Jul 27, 2011 at 23:15, Brzozowski, John john_brzozow...@cable.comcast.com wrote: From an operators point of view, specifically one that has deployed 6to4 relays, use of the same should not be encouraged. I fully hope and expect the use of 6to4 to systematically decrease over time so the associated infrastructure can be decommissioned. While we have seen issues related to 6to4 decrease recently the deployment of the same over the years, in particular open relays, has grossly complicated deploying 6to4 in a reliable manner. I have not been able to keep up with all the emails and threads related to this topic, I apologize for this. The bottom line from my point of view is that we (the IETF) should do something to discourage the use of the same. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 7/27/11 2:18 PM, Keith Moore mo...@network-heretics.com wrote: On Jul 27, 2011, at 3:32 AM, t.petch wrote: I oppose this action. I see clear evidence that 6to4 is damaging the Internet and although there are those who can use it without causing damage, I believe that the principle is 'First, do no harm' so the IETF has a responsibility to discourage its use. [...] I'd like to address the point that 6to4 damages the Internet. I do understand the content providers' argument - if 6to4 is turned on at the originator's host or network, the destination is advertising both A and records, and the record is chosen in preference to the A record, the user's experience is degraded. Sometimes the performance is degraded marginally (but the cumulative effect of lots of small delays on a web page that loads dozens of images is large). Sometimes it's degraded significantly because the 6to4 address doesn't work at all. Both cases matter, and they do provide a disincentive to content providers to just slap records onto their sites and be done with it. (There are other ways of a web site utilizing v6, but they require more work.) A lot of the arguments that I hear about 6to4 being bad in a universal sense seem to be based on the assumption that it's only access to content in the public Internet that matters. But anyone who has followed IPv6 development should know better than that. If access to content in the public Internet were all that mattered, there would have been no interest in ULAs. It remains the case that many enterprise networks have all kinds of internal resources that are useful to them even if they're not publicly addressable, and are only usable from within that network or from other networks with which they have made explicit arrangements. For better or worse, an explicit design feature of IPv6 is that hosts can have multiple addresses, and that different addresses might be needed in different contexts. A host's public address might be used when contacting a public web server, but when communicating within an enterprise network or between networks each using ULA space, the host might need to use its ULA address as a source address (the other host might not have a public address or the ability to send traffic to the public IPv6 network). I put the word feature in quotes because this can be a pain in the a** for applications and users. The default address selection rules don't really handle this case very well, nor can any set of static default rules handle this case. Essentially what having multiple addresses per host implies is that hosts or applications need to do routing in the absence of routing information. It shouldn't surprise anybody that the use of addresses that only work well (or at all) within a limited scope creates situations where a host will try to send traffic down a path that will never get it there, even when a different path would have worked. Introducing IPv6 - any kind of IPv6 - into a world of hosts that already support IPv4, creates exactly this situation. Nothing
