RE: Hyatt Taipei cancellation policy?
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Sunday, August 28, 2011 9:03 AM Subject: Re: Hyatt Taipei cancellation policy? I find that I work more effectively when I have computer and Internet available WEG] Me too, emphasis on the Internet. And this is exactly the reason why I simply don't buy the just find a cheaper hotel instead of the IETF one argument as the only solution for people put off by the price of the main hotel. Those staying in hotels with non-IETF internet access find that the combination of some non-trivial number of heavy internet users plus underprovisioned wireless, DHCP pool, and uplink, lack of IPv6 support + NAT = internet service that is somewhere between annoyingly crappy and unusably crappy. While I am somewhat sensitive to hotel price, for me, first-class internet service in my hotel room is worth a small bump in price so that I don't have to spend hours before and after sessions are over squatting in the conference area or hotel common area to get a decent connection to get work done. If you're willing to make that tradeoff in the interest of cheaper hotel, more power to you, but given the number of complaints about Delta's network in QC, I think that this is something that people tend to forget until they get there... (and before you say anything, I realize that Delta was the official overflow hotel, but I think the point is still valid). I'll also note that I don't think that it's strictly necessary for the hotel and conference center to be connected. I thought that the arrangement in Stockholm was quite nice. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IAOC, travel and hotel prices (was RE: Hyatt Taipei cancellation policy?)
I've been watching this discussion across several attendee lists, plenaries, etc and it appears that we have a routing loop. Perhaps it's time for those who seem most concerned about this to author a BCP draft regarding IETF meeting venue and hotel selection policies that addresses this, so that IAOC has a bit clearer instructions and a documented policy based on community consensus, rather than this discussion continuing to come up every couple of meetings, and the general response from the IAOC being this is hard, we're doing the best we can... [example, explanation] Not to say that I doubt the intentions or efforts of any of the IAOC folks past or present, but the theme I keep seeing in these discussions is a request for both transparency and price sensitivity, and I'm not sure that the feedback is being acknowledged so much as it is being treated as a request for explanation of the extenuating circumstances. It may also be advisable for the IAOC to start asking a few questions (via survey, for example): 1) What (if any) guidelines do(es) you(r company) follow for allowable hotel costs? 2) Would you prefer to subsidize the cost of the meeting venue with the cost of the hotel room, or via higher registration fees (or evenly split)? 3) Would you prefer the meetings to center on a few locations and negotiate an extremely good deal for repeat attendance (e.g. OFC/NFOEC, etc). a. Indefinitely rotate between the same 3 locations? b. Rotate on a 2 year basis (6 different locations) c. Rotate on a 3 year basis (9 different locations) d. Option a, but pick new venues every 2 or 3 years e. Status quo (venues completely variable) Additional questions about air travel and mass transit (the other perennial travel topics) might also be a good idea. Do it every year, or every 2 years or after every meeting when the previous meeting (good and bad) is still fresh in everyone's mind. Thanks Wes George From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Wednesday, August 24, 2011 8:37 AM To: Ray Pelletier Cc: John C Klensin; Secretariat IETF; IETF-Discussion list; Lixia Zhang Subject: Re: Hyatt Taipei cancellation policy? $300/night is far too high a ceiling for a guest room rate. A more reasonable ceiling would be in the ballpark of $150. On Aug 24, 2011, at 8:18 AM, Ray Pelletier wrote: The points are that the IAOC is not going to select a poor venue because it may have a sponsor; nor a $300+ USD guest room rate for the headquarters hotel. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Hyatt Taipei cancellation policy?
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Wednesday, August 24, 2011 8:37 AM To: Ray Pelletier Cc: John C Klensin; Secretariat IETF; IETF-Discussion list; Lixia Zhang Subject: Re: Hyatt Taipei cancellation policy? $300/night is far too high a ceiling for a guest room rate. A more reasonable ceiling would be in the ballpark of $150. I don't understand why we keep throwing around hard and fast dollar figures. Every person, whether paying their own way or using a corporate expense account is going to have a different view of what is ok vs what is unacceptably high, and that may or may not line up with the market rate reality of the actual location chosen. As others have pointed out in the past, the only limit that would make sense is to use something like the US gov't max travel rate guidelines, which are indexed to things like USD value vs. local currency, average cost by location, etc. We would likely need a percentage multiplier to compensate for the fact that we ask for breakfast, internet service, and conference fees to be waived in lieu of a cheaper hotel rate, but I think that's a reasonable rule of thumb. If there are alternative sources for the same data from EU or APAC government sources, they could also be used, but lots of folks already know about the US gov ones. US domestic rates are here: http://www.gsa.gov/portal/category/21287 International ones here: http://aoprals.state.gov/content.asp?content_id=184menu_id=78 If this becomes the stated policy, it makes available the negotiation tactic to note that we have a lot of members who follow the guidelines set forth here as far as how much they are allowed to spend per night for a hotel, if you insist on exceeding this by more than X%, we'll be forced to go elsewhere. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
From: Keith Moore mo...@network-heretics.com To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard I support publication of some document like this one. Suggestions for clarification to this document: 1. (section 2 in general) I think it's vague for this document to claim that it updates earlier documents as if it's changing the text of those documents. The reader is left with only a vague impression of what is still in place from those documents and what has changed. I suggest that the language in this draft be changed to first state each new or revised requirement, and then state how this changes recommendations/requirements stated in earlier documents. __ WEG] We received similar feedback in the intarea last call, the Updates... language in section two is an attempt to do this clarification and is far more specific than the 00 version. It was attempting to note that rather than updating the details of the technical specs, it was pointing out that IP as generic could mean IPv4 or IPv6, but these documents are clearly IPv4 documents. Think of it as equivalent to %s/IP/IPv4/g. Since it appears that this was not completely successful, I'd appreciate more specific feedback or text suggestions to make it better. 2. section 2, page 4 reads: reason: to me SHOULD NOT support IPv4 only seems potentially confusing. __ WEG] agree, will fix in next rev. 3. section 2, page 5 reads: New IP implementations MUST support IPv6. Current IP implementations SHOULD support IPv6. In general, it's meaningless to impose a requirement on current implementations of anything. WEG] This is why it's a SHOULD instead of a MUST. Also, generally this document is saying the IETF recommends that you support IPv6 so it seems a gap to leave out current implementations. This is also why the last paragraph in section 2 is there - we realize that there are going to be limitations to this and are trying to be pragmatic. Also, it's not clear what is meant by new implementations - does this mean completely new implementations, or revisions of existing implementations? WEG] I'm wondering if it actually matters in this context? They both need to support IPv6, which is why both requirements are there. Ultimately, this is going to be open to interpretation by implementers regardless of how it is worded. Since the IETF has no control over what they decide to do, if they choose to interpret their implementation as not new and therefore covered by the SHOULD instead of the MUST, IETF has no recourse if they disagree with that interpretation. That said, I am certainly open to additional text to clarify what new implementations are vs current implementations if you believe that it'll be helpful. Suggest that this be restated. e.g. Host and router IP implementations MUST support IPv6; to support only IPv4 is insufficient. WEG] This may be a way to solve. We'll consider in the revision. 4. also section 2, page 5: IPv6 support MUST be equivalent or better in quality and functionality when compared to IPv4 support in an IP implementation. This statement could be taken too broadly, e.g. as applying to service offerings rather than just host and router implementations. _ WEG] It was intended to be taken as broadly as possible. It's not necessarily limited to host and router implementations, though that is indeed its primary focus. How is it a bad thing if a service offering interprets this to mean that the IETF recommends that they support IPv6? Suggest instead: Support for the IPv6 protocol in hosts and routers MUST be equivalent or better in quality and functionality when compared to IPv4 support in the same products. Even then, this strikes me as problematic. Should an implementation that cannot provide support for every IPv6 feature (perhaps because of inherent differences between IPv4 and IPv6, or because some feature hasn't yet been updated to support IPv6) be expected to remove features from its IPv4 stack so that its IPv6 stack is equivalent or better? __ WEG] For what it's worth, I'm aware of several businesses that are using language similar to this in their vendor requirements documents. Basically, making it incumbent on the implementer to ensure that their gear supports features in both IPv4 and IPv6 rather than calling out specific features and thus risking missing some. So, I think the answer to your question is that it's a business decision on the part of the implementer. Some of the very early comments we received on this draft indicated a concern that people would implement the bare minimum IPv6 support and call it a day, making it mostly useless by comparison because it was so limited in functionality. This more generic text was chosen to cover this concern without getting us ratholed into a discussion about
Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
From: SM s...@resistor.net To: ietf@ietf.org Reply-to: s...@resistor.net Subject: Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard X-RSN: 1/0/933/10475/58528 From Section 1: However, due to the success of the Internet in finding new and innovative uses for IP networking, billions of hosts are now connected via the Internet and requiring unique addressing. That sounds like the requirement for unique addressing is a problem. The draft mentions that demand has lead to the exhaustion of the IANA global pool of unique IPv4 addresses. Should the above be read as requiring unique IPv4 addressing? _ WEG] You're reading too much into this. It's a statement of the current situation, not a discussion about whether unique addresses are good or bad. There are billions of hosts on the internet, a lot of them require unique addresses. End of line. No value judgment. A requirement for unique addresses is not a problem. However, it *is* a problem if all you have to address those nodes with is an exhausted IANA IPv4 free pool, which leaves us needing IPv6 to meet the demand for those unique addresses. However, the IPv6 deployment necessary to reduce reliance on IPv4 has been hampered by a lack of ubiquitous hardware and software support throughout the industry. Quoting RFC 5218: 'The lack of a value chain can make it difficult for a new protocol to progress from implementation to deployment to use. While the term chicken-and-egg problem is sometimes used to describe the lack of a value chain, the lack of implementation, deployment, or use is not the cause of failure, it is merely a symptom.' The assertion that the problem is a lack of ubiquitous hardware and software support throughout the industry is incorrect. It is the lack of the value chain that has hampered IPv6 deployment. _ WEG] I find it strange that you'd a) quote from a section of 5218 on protocol failure in a discussion about IPv6, which doesn't meet any of the criteria listed earlier in that section and b) invoke a value chain here as a reason to invalidate the above statement. Whether it's a cause or a symptom, the above quoted issue still exists as a barrier, and ultimately the lack of that support breaks that chain - no killer app making it attractive to move to IPv6 due to concerns that the target audience wouldn't be able to reach it, due to a lack of last mile support for IPv6, for example. I think this argument is mostly based on your following assertion, so I'll respond in more detail below. Many vendors in the consumer space such as Internet Service Providers still view IPv6 support as optional. They are still pushing the Internet as an IPv4 medium only. snip Even if the average home gets an IPv6-capable device, that would not get it any further due to last-mile issues. ___ WEG] As an operator (consumer ISP) who happens to spend a lot of time talking about IPv6 deployments with other operators, I disagree with this assertion. This is exactly the problem we're trying to solve. From where I sit, I see credible plans from a number of US residential broadband providers to have IPv6 enabled on a large portion of their footprint within the next 12-18 months. There is no reason why IPv6 support in ancillary devices needs to be a serial process dependent on completion of that last mile deployment. You're saying, don't bother, there's no IPv6 support on the last mile. We're saying we're building the last mile, and we'd like to not have to wait for the next technology refresh cycle before the IPv6 support we build has any devices to use it. Understand that in many cases, even if the providers turned on IPv6 support in the CMTS or DSLAM/BRAS tomorrow, if the customer supplies their own modem or wireless gateway, if it doesn't do v6, it's also all for n aught. Anyway, let's get to the meat of the draft. __ WEG] Brian's already responded to several of these items, so I'll respond inline in those messages as necessary. BTW, this draft has nine pages and four authors. The 162-page draft I read recently has five authors. If there is a desire to demonstrate how many companies are interested in this spec, a simple acknowledgment section can accomplish the same thing. ___ WEG] I fail to see the relevance of this other than to impugn the authors rather than the ideas in the draft, but since you brought it up, all 4 of the listed authors collaborated on the initial text of this draft at the end of IETF 79, and have provided material contributions to the text in each subsequent revision. I do not support the publication of this document as a RFC. It attempts to update old RFCs which are well-written in a confusing manner. The draft comes out as a statement about IPv6-required instead of a Proposed Standard. __ WEG] It would be helpful to know whether you do not support this because of the choice to
Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6Support Required for all IP-capable nodes) to Proposed Standard
From: t.petch daedu...@btconnect.com To: ietf@ietf.org Reply-to: daedu...@btconnect.com Subject: Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6Support Required for all IP-capable nodes) to Proposed Standard I find this document utterly bizarre and think it would seriously damage the Internet to publish it. WEG] well, I find the vehemence of your statement a bit bizarre, but I would like to address your concerns if possible. Please explain how a recommendation to support IPv6 is going to seriously damage the internet. The idea that ipv6 should be regarded as normal, as of equal standing to ipv4 is fine, the sort of statement that the IAB should make, or have made, as an RFC or in some other form. WEG] Agree. IETF has remained version-agnostic for some time now. But they have not made anything like the statement that this draft makes, which is that IPv6 will be necessary because IPv4 is going to have difficulties in continuing to provide the same level of service post-exhaustion. In the authors' opinions, it is long overdue as guidance to implementers, so we made the statement in the hopes that we'd reach consensus, which in a way is a stronger statement than something coming out of the IAB anyway. But this I-D claims Updates [RFC1122] to clarify that this document, especially in section 3, primarily discusses IPv4 where it uses the more generic term IP and is no longer a complete definition of IP or the Internet Protocol suite by itself. IPv4 is a phenomenal success, and RFC1122 is a key part of that. IPv4 was a confused jumble, as IPv6 is now, and RFC1122, with another two or so I-Ds, cut through the cruft and rendered it usable. IPv6 desparately needs an equivalent to RFC1122, as a trawl of the v6ops list archives shows, and clearly this I-D is never going to be it, but claiming that this I-D provides an update to RFC1122, coupled with its title, gives the message that there is not going to be such an I-D; IPv6 will remain a confused jumble (and so is unlikely ever to emulate the success of IPv4). ___ WEG] Ignoring for a moment the commentary on the state of the IPv6 RFCs vs IPv4, and the need for a rosetta stone, I'll note that the choice to update several IP(v4) RFCs was something that has been controversial based on Intarea LC feedback as well, but we believed necessary to provide the linkage between the two. Honestly, I would have rather seen IETF issue formal updates to the existing IP RFCs to include IPv6, rather than building an entirely parallel set of documents, but here we are, so we made a choice. It would be helpful to understand whether your resistance to this document is solely due to the decision to have this be standards track, to update several existing RFCs, or both vs the general recommendation that implementers should support IPv6. While I believe that removing the update references will reduce the impact of the document, I am not opposed to issuing a new version of the document that does so and keeps to simply documenting the requirements for IPv6 support if consensus supports that action. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
From: SM s...@resistor.net To: Brian E Carpenter brian.e.carpen...@gmail.com Reply-to: s...@resistor.net Subject: Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard Section 2 of RFC 4084 lists the primary IP service terms: (a) Web connectivity (b) Client connectivity only, without a public address (c) Client only, public address (d) Firewalled Internet Connectivity (e) Full Internet Connectivity And with the proposed update: (f) Version support. Does the service include IPv4 support only, both IPv4 and IPv6 support, or IPv6 support only? I don't think that it makes sense as it stands. If you want to wordsmith this, you could go with: (f) IPv4 Internet Connectivity. This service provides the user IPv4 Internet connectivity, with one or more static public IPv4 addresses. Dynamic IPv4 addresses that are long-lived enough to make operating servers practical without highly dynamic DNS entries are possible, provided that they are not characterized as dynamic to third parties. WEG] I think that you have a point that this update is a little weak in its current form. I don't have a problem with some clarifying text, but I think that the problem with the above is that you now get into situations where IPv4 internet connectivity by that definition is no longer possible due to a lack of available addresses. In other words, each of the defined items in the existing section 2 are applicable to IPv4 and IPv6 separately. So perhaps it needs to discuss the fact that there are now multiple permutations of the items in section 2, e.g. where the host has IPv6 internet connectivity, but really only has client/no public IPv4 connectivity. Then we're into value-judgment-land regarding whether full IPv6 connectivity coupled with NAT for IPv4 is considered full internet connectivity or if only true dual-stack is acceptable for that definition, etc. Brian was the one who originally suggested this RFC be added as updated by this draft, so I'm keen to hear his opinion as well. (g) IPv6 Internet Connectivity. This service provides the user/consumer IPv6 Internet connectivity, with at least a /60 IPv6 prefix. Dynamic IPv6 addressing that are long-lived enough to make operating servers practical without highly dynamic DNS entries are possible, provided that they are not characterized as dynamic to third parties. _ WEG] I think that this definition is going to be problematic. There are plenty of other documents which already define IPv6 connectivity, and we are unlikely to reach consensus on any definition that includes a prefix size, but I'd be interested in opinions on the rest of it assuming that the prefix size recommendation is dropped. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Tuesday, June 07, 2011 6:48 PM To: George, Wesley Cc: ietf@ietf.org; v6...@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC KMI've been using 6to4 on a regular, often daily, basis since the late 1990s. 6to4 has allowed me to develop IPv6 applications and test them on real networks, and deploy them in limited circumstances. 6to4 has also allowed me to remotely access computers on my SOHO networks, using any application protocol that I chose to do so, with out-of-the-box hardware and software, without any application-specific proxies, and generally without any application-specific configuration. None of these scenarios required a relay router. All of them were, and continue to be, useful. KM Yes, I've experienced on many occasions that using 6to4 to access dual-stack web servers doesn't always work so well. Sometimes it picks a suboptimal path because the relay router isn't convenient. Sometimes the v6 path doesn't work at all and the application has to time out and retry using v4. But this never really bothered me much, because my purpose in using 6to4 wasn't to try to access services that I could get to via IPv4 anyway. And neither, I suggest, is that a reasonable metric for evaluating 6to4 or any other IPv6 transition mechanism. The metric for evaluating an IPv6 transition mechanism should be based on its effectiveness in accessing services that are IPv6 only. WEG Again, are you or are you not using a relay router? You keep going back and forth. Bluntly, this isn't about whether you, or anyone else at IETF use 6to4. We are the longest of the long tail; the smallest percentage, the exception to the rule, not the exception that proves the rule. We're network geeks; we're willing to deal with dodgy connectivity or otherwise fiddly methods of doing things to test them and to prove a point. This discussion cannot be about whether the protocol should be preserved because some marginal percentage of folks in IETF use 6to4 successfully. I am not disagreeing that for some value of work 6to4 works to reach IPv6-only things. What I am saying is that the very things you illustrate here make it only acceptable for testing, and not for any sort of real substitute for IPv6 connectivity. What user is going to accept +100ms in latency due to suboptimal relay choice, or waiting multiple seconds for IPv6 to time out because 6to4 didn't work in that particular network setup? I think that the evidence says that 6to4 is actually *ineffective* by the evaluation you suggest - a good portion of the time it either utterly fails or provides such degraded service that it may as well not work. KM - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area. IPv6 is clearly the way that they want to go, but it's not widely available at present. 6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists. WEG So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployment of IPv6, not in spite of it. KM What you're saying is that applications developers shouldn't bother with actually trying to use IPv6 until the ISPs get their act together and deploy it. Well guess what? The ISPs have let us down. We've been waiting for 15 years for the ISPs to roll out IPv6, and for most of those 15 years they were all telling us that there were no applications for it. Now the ISPs are scrambling to get IPv6 into their networks, and they want to sabotage the IPv6 mechanisms that we have in place even before they are actually offering product. WEG Yes, yes, shame on the big, bad ISPs and their lack of deployment. Trust me, I'm as annoyed with the ISPs I've worked for and been a customer of that it is taking so long to get IPv6 out there too. But...6to4 sabotaged itself. This draft is acknowledging reality that it really didn't work the way we'd hoped. There is no active malevolence here on the part of the ISPs. In fact many of them (us?) have deployed or will be deploying 6to4 relays to improve the customer experience until native service is available, and are supporting the recommendations to make 6to4 suck less in draft-carpenter. KMWidespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price. In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Tuesday, June 07, 2011 11:21 AM To: George, Wesley Cc: ietf@ietf.org; v6...@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? KMThe best current use cases for 6to4 that I'm aware of are: KM- Applications developers want to be forward thinking and develop IPv6 apps, but cannot get native IPv6 access. 6to4 allows them to develop those apps and test or use them in useful situations (i.e. outside of a lab) without having to configure a separate tunnel to every host involved. Note that 6to4 is useful in this way even if all of the addresses used are 6to4 addresses, and the traffic therefore does not cross any relays between 6to4 and native IPv6. WEG Exactly my point. this is a valid use case, but 6to4 is by no means the only way to solve it. Application developers are welcome to set up an IPv6 network to test their apps against. That doesn't require IPv6 connectivity to the outside world. If you have more than one of any modern computer on your LAN and you turn the right knobs, they can all talk to each other via IPv6 independent of any external IPv6 connectivity. You seem to want to draw this distinction between IPv6 between two hosts using 6to4 since that works and using 6to4 as a means to connect to the IPv6 Internet via relays, but then you conflate them by repeatedly complaining about lack of IPv6 service available from most ISPs and presenting 6to4 as a solution. Further, I don't buy the separate tunnel to every host... thing. Tunneled IPv6 connectivity is widely available. All any developer needs to do if they can't get Native IPv6 and a tunneled application is deemed good enough for their testing purposes is connect both ends of their testing environment to their choice of tunnel broker, and through the magic of the internet, they're all connected to one another. KM - Enterprises have applications that need to be able to communicate with large numbers of hosts spread over a diverse area. IPv6 is clearly the way that they want to go, but it's not widely available at present. 6to4 provides them with a means of routing traffic to their hosts in the interim until widespread support for IPv6 exists. WEG So do IPv6IP or GRE tunnels. Been using one at home for 3+ years now. And honestly, if this type of application is going to be enterprise-class, it needs to be in conjunction with ISP deployment of IPv6, not in spite of it. KM - Users (including enterprise users) who have small networks with IPv4 access (generally behind v4 NATs) can use 6to4 to allow them to remotely access individual hosts on those networks. This can be done either with a NAT that also acts as a v6 router and supports 6to4 as an external connection, or by configuring the NAT to pass protocol 41 to a IPv6 router for the network, internal to the v4 NAT. WEG Until CGN becomes common, in which case 6to4 doesn't work again. Also, that same NAT + v6 router combination could just as easily manage a static tunnel. KMWidespread IPv6 support for native IPv6 would be when native IPv6 is available everywhere that IPv4 access is available, from at least one provider, with quality (connectivity, reliability, support) approximately as good as IPv4, and at a reasonable price. In other words, you can't expect applications to rely on native IPv6 until it's reliably available everywhere that they need to use it. WEG So Widespread IPv6 has to have reliability and support equivalent to IPv4, yet you're saying that you can expect applications to rely on 6to4 in the meantime despite evidence that it's unreliable, and the virtual guarantee that it won't be supported by the upstream ISP? And you and I disagree about the definition of widespread. I do not think that widespread means every small ISP in every corner of the world supports it ubiquitously and at every price point. I think it means it's available for a majority (50%) of Internet service customers. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. KM With respect, the v6ops working group is not in a good position to judge whether enterprise applications will use 6to4. Operators rarely have a good
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of TJ Sent: Tuesday, June 07, 2011 7:33 AM To: Tim Chown Cc: v6...@ietf.org WG; ietf@ietf.org Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC It's time to remove the stabilisers on the IPv6 bicycle. I agree, but get me native everywhere before taking away one connection mechanism that does work. This takes nothing away. It's not as if the day that this draft gets published as an RFC, 6to4 stops working. IETF has moved other protocols to historical status before they were out of heavy use, with the expectation that it would take some time for the alternatives to be deployed and existing implementations to be retired. This is specifically why we resisted the idea of putting in a shutdown schedule or other flag day where the 6to4 prefixes get null-routed, because it's likely to be different in each network and application. In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers and follow the recommendations found in [I-D.ietf-v6ops-6to4-advisory]. When traffic levels diminish, these routers can be decommissioned. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
At the risk of rehashing discussion from WGLC... Ole has addressed some of your points, I'll address a few others below inline. From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of Keith Moore Sent: Monday, June 06, 2011 1:22 PM To: ietf@ietf.org Cc: v6...@ietf.org; IETF-Announce Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) WEG Please substantiate these claims. What are the use cases, and why are there no other solutions for those specific use cases? What is considered widespread ISP support for native IPV6? The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations. 6to4 never was intended to have an evolutionary future. It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic. It is premature to recommend that 6to4 be removed from implementations. We do not know how long it will take ISPs to universally deploy IPv6. Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity. WEG As was discussed in the WGLC for this document, enterprise applications will not realistically use 6to4 as a means to reach IPv6 for business critical applications. It's simply not reliable enough. It's also probably unlikely that those will go directly to IPv6-only vs using dual-stack to ease that transition. Individuals and Enterprises that use IPv6-only applications will need to make IPv6 service a non-negotiable requirement for their ISPs, networks, and devices rather than hoping that 6to4 works. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6. In many cases the criticisms are overbroad. Not all uses of 6to4 involve relays. For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party. WEG Again, please substantiate this with examples of implementations that are actively using non-relay 6to4. Also, the number of applications of 6to4 that can be guaranteed to avoid any unknown 3rd party relays is extremely limited due to the nature of anycast and 6to4's asymmetric routing. The protocol action requested in this draft in no way prevents one or more consenting networks from using 6to4 and continuing to run relays for their local traffic indefinitely - in fact, it even provides a reference to a document to show them how to make it work as well as possible. It is simply saying that it's not a good idea. The recommendations to treat 6to4 as a service of last resort will do harm to users and applications using it. A better recommendation is for hosts to disable 6to4 by default. WEG this seems to be to be splitting hairs. Please explain the distinction you're making here. Disable by default means never use. Use as last resort means use when no better IP connectivity is available. I would think if you insist that 6to4 must stick around you'd prefer it to be enabled. I understand that there are different values of better but if 6to4 works, this means that the host is not behind a NAT, and therefore by most definitions, its IPv4 connectivity would be better than 6to4. If it's behind an IPv4 NAT, and therefore IPv6 connectivity would be better (especially if there are one or more applications that work via IPv6 but not via IPv4 + NAT) then 6to4 won't work in lieu of IPv6 connectivity anyway. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org
