Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli joe...@bogus.com wrote: The queue for dicussion of this point is closed. If there needs to be an appeal on this point now or in the future, then I'll be happy to help someone write it, but I consider that dicussion settled for the purposes of a draft that has already been tested for wg acceptance/wglc/ietf-lc To clarify - you're talking only about the discussion on whether this draft is in scope? Or are you saying that you consider all discussion of this document in this IETF last call settled?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote: Having consent form all vendors is valuable but I'm afraid this is not the goal of this document. If not all vendors, then what about some vendors? Is it a goal of this document to have consensus from some implementors? Or is consensus from implementors a non-goal?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Sep 9, 2013 at 9:16 PM, mohamed.boucad...@orange.com wrote: * NEW:* * * NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the** ** previous section only for precision. * * That's better, thanks. I still think it's important for the document to say that it's not necessary to do all mountain of work to deploy IPv6, because otherwise there's the risk that product managers/implementors will say, Wait, are you're saying that to deploy IPv6 we have to do all that work? We can't do all that. Let's focus on something else instead. How about changing is not required in order to claim conformance with IETF standards for IPv6 to is not required to deploy IPv6 on other networks or to claim conformance with IETF standards for IPv6?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:57 PM, mohamed.boucad...@orange.com wrote: I have considered that Lorenzo. “is not required to deploy IPv6” would be accurate if this document is dealing only with dual-stack, but this is not true for the IPv6-only mode. The set of SHOULD recommendations are targeting that deployment model. I disagree. By my reading, you can make a phone that works perfectly well on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this document. If you want to do IPv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23). But the other ones are not necessary to deploy an IPv6-only phone. One of your co-authors will be able to confirm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of them implement all the requirements in this document (or even all the MUSTs). [*] How did #18 even make it in? What use is a MAY in a requirements document? Of course implementors MAY do anything they want, unless they SHOULD NOT or MUST NOT.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 3:27 PM, mohamed.boucad...@orange.com wrote: How can we ensure every implementers will agree with this list? For instance we have two detailed technical reviewers Are reviews still appropriate? I think there are a lot of things left to say about this document beyond the high-order points we're discussing at the moment. If I write them down, will they be considered or will the answer be that it's too late to accept feedback because the document is already in last call?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 5:18 PM, mohamed.boucad...@orange.com wrote: I really don’t see how you can have a phone that “make a phone that works perfectly well on an IPv6-only” if you don’t support IPv6/IPv4v6 PDP context You don't need to support IPV4V6 if all you need to do is work on an IPv6-only network. That might seem like a stupid answer, but the point I'm trying to make is that while you and I know that supporting only IPV6 will result in the phone being incompatible with some networks *the document doesn't say that*. The document says you MUST support all this stuff, without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected. That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else. you don’t have a means to make work broken applications when IPv6-only is enabled Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. if the phone does not follow the procedure for requesting the PDP context, You don't need to do that if you have an APN database that's configured with what the operator supports, or if you don't support IPV4V6. (Straying back into technical discussion for a bit - from a technical point of view, having seen the wide variety of behaviours and result codes that basebands typically exhibit when you ask them to do something that they or the network doesn't support, I think relying on this fallback is a terrible idea.) how you can be compatible with DNSSEC, etc. How many phones today support DNSSEC? NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This is not about IPv6-only mode. That's a useful feature, and as I'm sure you know, it's been implemented by a number of manufacturers. Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. I don't consider these to be degraded service, I consider them to be a lot better than what we have today. But someone taking this document as a guide to what needs to be implemented to deploy IPv6 would consider them to be incomplete or broken implementations. Such a person might look at the 34 requirements and just give up, when in fact such an implementation is perfectly capable of doing IPv6 today.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Tue, Sep 10, 2013 at 8:12 PM, mohamed.boucad...@orange.com wrote: *[Med] No. no, no the document indicates the language for each feature: there are MUST, SHOULD, etc. This is not the first time a document makes such classification of the features.* Sorry - what I meant is: most of the text in the document says that devices MUST support this, SHOULD support that, SHOULD support the other, but not much time saying why. ** *[Med] There is already motivations text for most of features, rationale and scope of the overall effort in the draft. You are continuing ignore it. That’s not fair.* Isn't it? For example, look at RFC1122 and compare it to this document. Compare the percentage of text used to state requirements and the percentage of text used for rationale. If anything, an informational document should have fewer requirements and more rationale than a standard, not the other way around. Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). *[Med] There are API, there applications shipped by device vendors themselves, etc. Our teams already tested applications provided by vendors devices which are broken when IPv6-only mode.* Then change the requirement to say vendor applications must not be IPv4-only. At least it's a reasonable request (though one that's unlikely to happen before IPv6 is widely deployed). All apps is not a reasonable request. * * The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. ** *[Med] Are you saying this is a MUST?* I don't think this document should be a bunch of MUST this, SHOULD that, MUST the other. As regards 464xlat, I think that shipping an IPv6-only phone without 464xlat or something equivalent equals shipping a phone that's not useful, and that doesn't happen in the real world. So if you want to ship IPv6-only, you need something like 464xlat. Does it follow that a phone MUST implement 464xlat? No, it does not. ** *[Med] How many device support IPv6 today? We can play that game endlessly...* Not really, because upwards of 30 million mobile devices are using IPv6 every day on Verizon Wireless alone. See: http://conference.apnic.net/__data/assets/pdf_file/0017/50813/vzw_apnic_13462152832-2.pdf http://www.worldipv6launch.org/measurements/ Those phones do not meet the requirements of this draft. They violate at least MUSTs in #16, #20, #24, #27, #28, plus a large number of SHOULDs. According to the text in -05, that means they cannot connect to an IPv6-only or dual-stack wireless network including 3GPP cellular network and IEEE 802.11 network). I know that text won't be there in the next version, but the point I'm trying to make is that the document made it all the way to IETF last call while claiming that largest deployment of IPv6 in a mobile network was not possible. I don't want that to be the message coming out of this document. NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). ** This is not about IPv6-only mode. *[Med] What is wrong in that text? Can we focus on the exact text change?* The operators proposing this profile believe that the support of a subset of the features included in this protocol may lead to degraded level of service. * * Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. ** *[Med] You still do that. These features are not MUST in this document. It is your right to ignore them but you need to be aware this may have some negative impact. It seems you understand the list as MUST ones…while this is not true.* Per the document, if you implement IPv6 tethering you MUST implement a full RFC 6204 router in the device (req#28). * * ** I don't consider these to be degraded service, I consider them to be a lot better than what we have today. *[Med] I’m sorry to say that a customer with IPv6-only connectivity that cannot use some applications available for an IPv4 customer is a degraded service. This is seen by some operators as a barrier for that mode. * I stand by my opinion that IPv6 tethering without a full RFC6204 implementation and that 464xlat without a local DNS64 implementation are not degraded.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland d...@cridland.net wrote: I'm not sure the consensus requirement you're suggesting actually exists. This is aiming at Informational, and as such: An Informational specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational [RFC 2026 §4.2.2] Fair enough. But the document then proceeds to use RFC2119 normative language, which is not appropriate because it's not a standards track document. Normative language is not appropriate for informational documents; there was a big discussion over that for RFC6092, and that ended up being published with a note well saying, this document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. You may note that no such conformance is not required text is present here. This is at best confusing and at worst misleading. If this document were to plainly state that it simply represents the set of features that a particular set of operators feels is necessary for IPv6 deployment on mobile networks, but that it is not an IETF standard, and compliance with it is not necessary to deploy IPv6 on mobile networks or to claim conformance with IETF standards, I would have no objection to it. But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works. No, the IETF has published profile documents in a number of cases. One could argue that RFC 1122 and RFC 1123 are both profile documents, actually, but there are other specific examples, like the Lemonade profile, for example. I had written a few paragraphs explaining why this document and RFC 1122 / 1123 are not even remotely comparable, but I think that's beside the point of this discussion. I think the main point is that RFC 1122/1123 are standards and this document is not intended to be one. I suspect, however, that this document is actually a standard, or intended as one. There's discussion about conformance, about testing for conformance, and so on, which suggests that an operator (in particular) might treat any resultant RFC as a standard without regard for its IETF status. Absolutely. Such an operator might well decide to say that the requirements for all devices on their network are captured in this standard, and the IETF would have nothing to say about it. But the point is that it would be the operator setting the requirements, not the IETF. The IETF cannot set requirements in an informational document. That's a concern, though in practise, if this is to be a document detailing what operators want, I'd be happier that it's published through the IETF as Informational than not published at all - and in any case, no amount of pretence will alter the fact that people will treat any RFC as a standard if it suits them anyway. Sure, but if said document said this is not a standard in so many words, then that would be a difficult position to convince others of.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Sep 9, 2013 at 8:06 PM, mohamed.boucad...@orange.com wrote: The document explicitly says “This document is not a standard.” since version -00. ** ** What additional statement you would like to see added? I think the high-order points are: 1. The text This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network should be replaced with This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). In place of a number of operators believe is necessary to deploy you could have intend to deploy or require. I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? 1.3. Use of Normative Keywords NOTE WELL: This document is not a standard. Conformance with it is not required to deploy IPv6 in mobile networks or to claim conformance with IETFstandards for IPv6. It uses the normative keywords defined in the previous section only for precision. Regards, Lorenzo
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 3:31 PM, mohamed.boucad...@orange.com wrote: it is about ** a ** profile for mobile devices. But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). The draft seems implies that all these requirements must be met to deploy IPv6 on mobile devices, but that's not true. A great example is the statement in the abstract which says that this document lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network. This statement is false: there are tens of millions of mobile devices using IPv6 every day, and none of them meet more than a minority of the requirements in this document. I know we've already gone over this in the WG, but since this is IETF last call, I think the rest of the community should see this discussion so that we collectively know what the arguments for and against this proposal and can reach informed consensus. Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 5:29 PM, david.bi...@orange.com wrote: ** But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs. Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). [[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document. And how is it that you as an operator need all devices to meet requirement #28 (a cellphone MUST also be a CPE router)? How can you say that it's necessary to facilitate deployment? Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some. Remember, the IETF is supposed to be about rough consensus and running code. Can we wait until there is at least one implementation that does all this before we publish the document?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 6:07 PM, mohamed.boucad...@orange.com wrote: Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? ** *[Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time.* Then state in the document that this profile is recommended by the IETF, and if you get consensus on that, great. But the document should say *something* about this. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That’s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. *[Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear.* True. The document does define cellular device as something that's capable of sharing WAN connectivity. I don't suppose you could pick another word than device here? It's confusing, because device usually refers to any engineered object. Maybe use the word sharing or tethering in the name? *[Med] There is running code for several features listed in this document. Because we don’t have “decent” implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!!* But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Aug 19, 2013 at 10:52 PM, The IESG iesg-secret...@ietf.org wrote: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). I object to this document on the grounds that it is little more than a list of (34!) features with little technical justification. I see this as a problem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify which features or protocols should or should not be implemented in hosts. Even the hosts requirements RFCs are careful and sparing in their language. The IETF is certainly not in the business of rubberstamping feature wishlists without good technical reasons. I would challenge the authors to find a precedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necessary to build a mobile device that works well over IPv6. Today, the overwhelming majority of mobile device traffic comes from devices that implement only a handful of these requirements. More specifically, requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applications running on the device - yes, all of them), and #34, are not necessary to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would challenge the authors to find a single product today that implements all, or even a substantial majority, of these requirements. It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. 4. The document has few technical contributions of its own. Most of the requirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what seems like all the features that the IETF has ever developed, and then saying that they all need to be implemented, is not the way to get there. The way to do it is to document use cases and working scenarios gleaned from operational experience. Regards, Lorenzo
Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC
On Thu, Feb 16, 2012 at 00:52, Livingood, Jason jason_living...@cable.comcast.com wrote: To be more specific, at least section 5.5 (it is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice) is now incorrect. It *is* clear, and it's what those implementers are doing as part of World IPv6 Launch. Does that make more sense? As the author, if it helps I plan to make the following change to Section 5.5 following the conclusion of IETF Last Call. I ran this by a few folks already and it seems broadly acceptable (have not heard from Lorenzo yet though). Jason *CURRENT 5.5: * 5.5. Turning Off DNS Resolver Whitelisting Domains that choose to implement DNS Resolver Whitelisting generally consider it to be a temporary measure. It is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice, though the extent of IPv6 deployment to end users in networks, the state of IPv6-related impairment, and the maturity of IPv6 operations are all clearly factors. However, implementers may wish to take into consideration that, as a practical matter, it will be impossible to get to a point where there are no longer any IPv6-related impairments; some reasonably small number of hosts will inevitably be left behind as end users elect not to upgrade them or as some hosts are incapable of being upgraded. *PROPOSED 5.5 (NEW TEXT IN ALL CAPS):* 5.5. Turning Off DNS Resolver Whitelisting Domains that choose to implement DNS Resolver Whitelisting generally consider it to be a temporary measure. It is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice, though the extent of IPv6 deployment to end users in networks, the state of IPv6-related impairment, and the maturity of IPv6 operations are all clearly factors. However, *SOME IMPLEMENTERS HAVE ANNOUNCED THAT THEY PLAN TO PERMANENTLY TURN OFF WHITELISTING BEGINNING ON WORLD IPV6 DAY IN JUNE 2012 [REFERENCE]. IN ANY CASE*, implementers may wish to take into consideration that, as a practical matter, it will be impossible to get to a point where there are no longer any IPv6-related impairments; some reasonably small number of hosts will inevitably be left behind as end users elect not to upgrade them or as some hosts are incapable of being upgraded. eom I think the suggested change does not go far enough. The high-service-level domains that prompted this draft to be written, and all the implementers I'm currently aware of, are decommissioning the practice. So the paragraph that states, It is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice is still incorrect. Can you just remove the paragraph and start the section with Many implementers have announced that they plan to permanently turn off whitelisting beginning on... ? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC
On Thu, Feb 9, 2012 at 00:36, Joel jaeggli joe...@bogus.com wrote: Ops is not marketing. And if I were looking for a marketing venue, a standards body that produces ASCII text documents read by a handful of engineers would not be high on my list. This is not about marketing. If you're saying some flag day makes the contents of the document no longer operationally relevant after a given date, I'll take the point but disagree. I think you're missing my point. It seems to me that approximately 30% of the non-biolerplate text in this draft discusses DNS whitelisting. (And in fact, in its original form the draft entirely on DNS whitelisting - hence the filename. The rest was added later.) Whitelisting is a practice relevant to a few large websites (since nobody else is using it). It so happens that the websites that employ this practice are going to stop using it, all together. Given the cost and implications, I'd say practice is unlikely to be resurrected. So, you decide to tell the whole story, and talk about whitelisting *and* World IPv6 Launch. Or you can decide that whitelisting will soon be irrelevant, and not talk about either whitelisting or World IPv6 Launch. But you can't talk about whitelisting without talking about World IPv6 Launch, because if you do, your document is missing the key piece how do you remove the whitelist, and that's a disservice to its readers. To be more specific, at least section 5.5 (it is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice) is now incorrect. It *is* clear, and it's what those implementers are doing as part of World IPv6 Launch. Does that make more sense? Cheers, Lorenzo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC
On Sat, Feb 4, 2012 at 01:35, Fred Baker f...@cisco.com wrote: The IESG again decided it needed a revised draft, and that draft - in large part, a rewrite - arrived in October. v6ops had a second WGLC, in which you again declined to comment, although you may have seen Lorenzo's comments, which were picked up in a November version of the draft. Ralph and Jari finally cleared their discuss ballots a couple of weeks ago, and we are having a second IETF last call. I'd like to understand your objective here. I know that you don't care for the draft, and at least at one point took it as a somewhat-personal attack. Is your objective to prevent the draft's publication entirely, or do you think that there is value in publishing it given a productive response to this comment? At what point are you willing to either participate in the public dialog or choose to not comment at all? Ok, let me see if I can rephrase Erik's objection. The draft needs to take World IPv6 Launch into account, because it's a key piece of the puzzle. We can't publish an RFC on how to transition content to IPv6 if the RFC ignores the event when 5 of the top 10 websites in the world (and probably many more) will permanently enable IPv6 for everyone. Cheers, Lorenzo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Thu, Jul 28, 2011 at 01:30, james woodyatt j...@apple.com wrote: http://www.pam2010.ethz.ch/papers/full-length/15.pdf Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig 3); about 90% MacOS hits is 6to4, which possibly means (to me) that this piece of 6to4 MacOS software of yours represents a third of global IPv6 traffic. Would you care to comment on the numbers? p1. Those numbers are badly outdated. Speaking as one of the authors of that paper: correct, the numbers are badly outdated. You can find the more recent numbers resulting from those measurements at: http://www.google.com/intl/en/ipv6/statistics/ You will see that 6to4 now accounts for approximately 10% of total IPv6 traffic as measured using that methodology, and is steadily declining (modulo seasonal variations like the French going on holiday). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Thu, Jul 28, 2011 at 16:51, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Clarification: in your stats, is AS12322's traffic classified as native or as 6to4/teredo? As the webpage says: The Total IPv6 graph shows IPv6 users with any type of connectivity, while the Native IPv6 graph excludes users using 6to4 or Teredo. ___ 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: draft-ietf-v6ops-6to4-to-historic (yet again)
I support this proposal, for the following reasons: 1. Google's public IPv6 adoption data [1] shows that from the perspective of a website, 6to4 is a tiny and decreasing percentage of IPv6 clients. 2. Geoff Huston's data, presented at v6ops in Prague, shows that 6to4 failure rate when connecting to dual-stack destinations is approximately 20%. 3. Large website operators such as Google, Yahoo, and Facebook have data that show that 6to4 is an important reason for a large percentage of dual-stack brokenness, and that dual-stack brokenness is the main reason why their websites do not have IPv6 records today. Lack of IPv6 content is one of the reasons most often cited by access networks when explaining the lack of IPv6 deployment to end users. 4. A number of home gateway manufacturers are still coming out with new devices that support 6to4 and even enable it by default when IPv6 is enabled. Declaring 6to4 it to be historic would help ensure that those manufacturers disable 6to4 in future products. 5. The advent of large-scale NAT will decrease the applicability of 6to4. 6. The advent of ISPs assigning bogon address space to users will substantially 7. For those who want to do application development using IPv6, there are alternatives to 6to4, such as manually configured tunnels. These are readily available, work behind NATs, and in many cases offer lower latency and higher reliability. [1] http://www.google.com/intl/en/ipv6/statistics/ On Tue, Jul 26, 2011 at 09:47, Ronald Bonica rbon...@juniper.net wrote: Brian, Does the following text work for you? Ron N. Meaning of HISTORIC For the purposes of this document, the term HISTORIC means: - 6-to-4 should not be configured by default on any implementation (host, cpe router, other) - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products. - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Monday, July 25, 2011 11:09 PM To: Ronald Bonica Cc: ietf@ietf.org Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) To be clear, I'd like to see exact proposed text before expressing support for the proposal. The trick is to get 6to4 disabled by default at the user end, without disabling it for users who are getting good service from it. Regards Brian On 2011-07-26 09:49, Brian E Carpenter wrote: Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. This is, of course, an undeniable statement of fact (as it is for any other feature of the Internet). However, it needs to be made clear that doing so *prematurely* would penalise existing successful users of those relays, and therefore it should only be done when there is no successful traffic through them. Which is when any operator would remove them anyway. Therefore, I don't see much value in this statement, and possible harm to users. The ways to avoid such harm as far as possible are already in the RFC Editor queue. Regards Brian Carpenter On 2011-07-26 02:30, Ronald Bonica wrote: Folks, After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. Please post your views on this course of action by August 8, 2011.
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: We know it can operate correctly and reliably if it is configured correctly. ... and in networks where there are public IP addresses and no firewalling, and... etc. etc. But we already had this discussion on v6ops, and since the consensus of the WG was that the draft should be published, there's no point having it again. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore mo...@network-heretics.comwrote: Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community. And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: I think there is pretty much complete consensus that i) 6to4 doesn't work in several very common environments (behind a NAT, etc, etc), and that therefore, ii) at the very least, it should be disabled by default (and therefore only turned on by knowledgeable users who know they are not in one of those situations). Given and assuming a document that makes all that formal, _what else_ does the _additional_ step of making 6to4 historic buy? Compared to the alternative of publishing 6to4-historic now, it: a) Delays the time of any statement made by the IETF on the question by at least a number of months, while vendors and home gateways are *still shipping* products that implement 6to4 and enable it by default. I have personally seen this in beta home gateway products with new IPv6 firmware that aren't even released yet. b) Even assuming it were to gain consensus in any sort of reasonable timescale, it would provide a less clear statement, and thus be less of an incentive for implementors such as home gateway manufacturers to do the right thing and remove it. We have heard in the working group from real implementors like Apple, who have said that even 6to4-historic may not go far enough for them to justify actions such as removing support from their products. We have heard, also, that when implementors such as home gateway manufacturers are asked to remove 6to4 or disable it because it harms user experience, they say that they don't see why they should do work to remove a feature, in the absence of any guidance from the IETF. Time is important, because over time, 6to4's reliability will get worse, not better, as ISPs do things like use bogon IPv4 space plus carrier-grade NAT for their users, because implementations will think they have public IPv4 addresses and thus turn on 6to4 (which will never work, because it's behind a NAT). Or perhaps the concept is that nuking 6to4 will help force ISPs to deploy native IPv6, since it removes one way for users to get IPv6 if their provider doesn't supply it? If so, why not ditch Teredo, too? (Not to mention that 'mandate it and they will come' hasn't worked to well so far.) Normal users will not get IPv6 unless their ISP gives it to them. Period, end of story. I think it's clear by now that the vast majority of users don't know what IPv6 is, and that they do not ask for it. For a normal user, having 6to4 is more a liability than an asset. Normal users don't rely on 6to4 to give them IPv6 connectivity, because they don't use or need IPv6; everything they do today can be done with higher performance and higher reliability using IPv4 and NAT traversal. However, if they get it for free in the form of 6to4, then far from gaining a benefit (reliable IPv6 connectivity), they get something that only works 80% of the time, and 20% of the time breaks dual-stack websites. By users I explicitly do not include the tiny percentage of users on this list who are technical enough to know that 6to4 exists and rely on it to get IPv6 connectivity. Compared to the overwhelming number of users who have no idea what IPv6 even is, they are so far away from the mainstream that they don't matter at all, and they are knowledgeable enough to deploy other solutions, such as managed tunnels, which in my experience are typically lower latency and higher reliability (pretty much everything is higher reliability than a 20% failure rate). The only way you can incentivize ISPs to deploy IPv6 is to provide IPv6 content that they can use to justify the investment (for example, reduce the load on the NATs that they will be deploying). ISPs have been saying for years, and are still saying, that one of the reasons tha they are not deploying IPv6 because there is no point, since so little content is available over IPv6. Now we are hearing clearly from content providers that they *do not want* 6to4, because its 80% failure rate is a concern for them, and that in fact, its existence is one of the major barriers to lack of adoption on the part of content providers. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore mo...@network-heretics.comwrote: And who says that rough consensus of the entire IETF community is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? There's clearly a lack of consensus to support it. Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it? If all you can point to is the same people that were opposing it in v6ops, then I think they don't count, because the rough consensus in v6ops was that the document should be published. So, I ask again: where are the statements made in opposition of this proposal made outside of v6ops? Can you point to them? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: Declaring 6to4 to be historic might encourage native IPv6 deployment, but I think it will also make trialing IPv6 much harder. We don't need to trial the IPv6 protocol. There are hundreds of thousands of native users accessing production-grade IPv6 services, like Google's, every day. We know the IPv6 protocol works. ISPs do need to trial IPv6 deployment. But 6to4 does not help there, because 6to4 is not deployed by ISPs. They will need to trial native deployments, or 6rd. If *users* want to trial IPv6 until native IPv6 is available, then they can use configured tunnels. The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any problems with it are tractable. I would assert that the problems with 6to4 are not tractable without disabling 6to4. Our IPv6 brokenness statistics for before and after World IPv6 Day are very similar. 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users. No, that's not how it works. There is no problem with 6to4 when it works as well as IPv4. The problem is that 6to4 only works *at all* (never mind works as well as IPv4) 80% of the time. Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the record is handed out, the damage is done. What Google could do, however, is stop handing out records to networks that have significant number of 6to4 users in the future. We're considering this. An update on that data would be useful. As I said before, our data on IPv6 brokenness did not change significantly after World IPv6 Day. Can you take that as a proxy that 6to4 has not improved? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: I don't object to what has been proposed, yet I object to 6to4-historic because I'm an extremely happy anycast 6to4 user It works for me, so there's obviously no problem. When you think of 6to4-historic, please think of the 20% of anycast 6to4 users that are broken. We know it can operate correctly and reliably if it is configured correctly. But we also know that it's not configured correctly, to such an extent that it does not work at all in 20% of cases (Geoff's data). And we know of no reason why that would improve, though we do know of reasons why it would get worse (e.g., due to ISPs giving bogon public space to their users). ___ 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
On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org wrote: I don't know if it is intentional, however if I use Google's public 8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4 (via /etc/gai.conf under Linux/glibc), it seems that the video content of all youtube videos is now being delivered over IPv6. Yes, YouTube videos are currently being served on dual-stack hostnames. The percentage of YouTube users that uses 6to4 is less than 0.02%. The percentage of YouTube users that uses native IPv6 is approximately 0.2% - over 10x more. That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? I'm having and have been having 100% success rate (or near enough to it that I can remember) using 6to4 for a number of years, including with an IPv6 MTU of as large as my PPPoE connection will support i.e. my 6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos are coming over IPv6, I've paid a bit more attention to the quality of experience I've had, and have not found any reasons to change my preference back to native IPv4 instead of 6to4. Sure - you're one of the 80% for whom it works. But that wasn't my question - my question was what is the advantage? You said that you have near enough 100% success rate, but I bet that your IPv4 success rate is near enough 100% as well. So what are you gaining by using 6to4 to talk to YouTube? ___ 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
On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.comwrote: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network ... about 80% of the time. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, and that case 2 is today solved more reliably, and in more cases (e.g., when no public IPv4 address is available at the border) by the various NAT traversal mechanisms that are implemented in applications. But I think we're just going around in circles here. ___ 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
On Wed, Jun 15, 2011 at 6:21 PM, Mark Andrews ma...@isc.org wrote: ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. No, because you often end up being dependent on the whims of BGP and third-party relays for your return path. Sure, if you have enough control over routing in a closed network, you can make sure the right relays are used. But in that case, why not use configured tunnels? 6to4 historic is throwing the baby out with the bath water. On this we know we disagree. ___ 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
On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? ___ 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
On Fri, Jun 10, 2011 at 9:18 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. ... So the existence of 6to4 is in itself a significant barrier for IPv6 deployment Surely you meant to say the _incorrect configuration_ of 6to4 is in itself a significant barrier? You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. I get the impression that the problem comes in when 6to4 is configured on by default, and too high in the priority list (as opposed to native, other methods, etc). So fix the real issue, don't try and prematurely kill off something that's being used by lots of people. I fundamentally disagree. I really don't think that 6to4 is used by lots of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. ___ 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
On Fri, Jun 10, 2011 at 10:15 AM, james woodyatt j...@apple.com wrote: I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Yes, of course. I was trying to keep it short. ___ 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
On Tue, Jun 7, 2011 at 11:20 AM, Keith Moore mo...@network-heretics.comwrote: Indeed, that is one of its main virtues. 6to4 decouples application deployment of v6 from network deployment of v6, and helps reduce the chicken or egg problem. No, it does not - in fact, it is the opposite. Geoff has presented data that shows that anycasted 6to4 as a connectivity mechanism has a failure rate of the order of 20-30%. We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. Search the list archives for details. So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. And if you believe the access networks, the lack of IPv6 content is one of the most significant barriers to IPv6 deployment in access networks. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. ___ 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
On Tue, Jun 7, 2011 at 3:47 PM, Keith Moore mo...@network-heretics.comwrote: Why are you trying to make life harder for developers of IPv6 applications? There's no reason at all that an application developer should have to set up a special-purpose network just to test an IPv6 application. No, we're trying to make their lives easier, by suggesting they use something that actually *works*. Realistic testing of applications needs to be done on real networks, or a least an approximation to real networks. Testing IPv6 using 6to4 over public IPv4 obviously isn't perfect, but it's a hell of a lot more realistic than setting up a lab network and confining one's testing to that. So use a tunnel broker. You're missing something. I can connect directly from my mobile laptop to a machine in my home network using 6to4. Really? From where? On none of the networks my laptop connects to do I get a public IPv4 address. Some of them do give me have native IPv6 or manually-tunneled IPv6 though. We can disagree about the meaning of the word widespread, but the practical fact is that you can't expect people to give up something that works for them until you can provide them something that works better *for them. Available to 50% of Internet service customers is equivalent to a very small percent probability of native connectivity being able to replace 6to4 connectivity in a scenario where 6to4 is currently working. And the more hosts involved, the smaller that probability is. * You cannot claim that 6to4 is working when there is data that shows that it has a 20% failure rate. If we had that sort of connectivity in IPv4, we wouldn't have an Internet. Existing content providers are not going to drive adoption of IPv6. They're going to follow it. Nope. Look at World IPv6 day. If you look at the list of participaints, I'd say that probably more than 10% of Internet content, either by bits or by query volume, is ready for IPv6 now. Our data shows that access is at 0.3%. So you could say that in fact content *is* driving adoption of IPv6. We just need to get unreliable tunneled connectivity out of the way so we can turn it on for real. Web and email will be the last applications to migrate. Um, no. See above. WEG Well, it'd be more harmful if there weren't alternatives. There aren't any good ones. Teredo and configured tunnels are worse in many ways; though they each have their use cases. Actually, configured tunnels are much better. They have a much lower failure rate and lower latency. We published data that shows the latency impact in our PAM 2009 paper. Regards, Lorenzo ___ 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
On Wed, Jun 8, 2011 at 1:19 PM, Keith Moore mo...@network-heretics.comwrote: Again, 40-something percent of the IPv6 traffic that is observed on the net today uses 6to4. Please point at the data behind that assertion. In many cases in the past, such assertions have comes from networks that do not have the hardware capabilities to monitor native IPv6 traffic. I remember one case at the RIPE meeting where someone from AMS-IX observed about one of these presentations, I have more native IPv6 traffic on my exchange point than you have observed in the entire Internet. How is that possible? Needless to say, that presentation did not go well. Look at http://www.google.com/intl/en/ipv6/statistics/ That obviously does not see peer-to-peer traffic, but it does see IPv6 web clients, and just under 90% of those are native. The evidence is that people are using it. You're trying to subject it to test cases that are largely meaningless - because in those cases IPv6 (of any kind) provides no marginal value in the near term. So far, you have provided solid evidence that *you* use it, but not solid evidence that people are using it. Can you point to that evidence? Almost all usage of IPv6 today is in spite of ISPs. For that matter, a great many successful IPv4 applications today are deployed in spite of ISPs. Again, ISPs in general have let us down, and 6to4 and Teredo are carrying ~90% of IPv6 traffic. ISPs are not in a good position to demand that 6to4 be deprecated. Nope. As before, 90% of IPv6 is native, and it comes from a small number of large deployments. Maybe your ISP doesn't support it, but other ISPs do. It's not one versus the other. 6to4 is helping to promote ubiquitous IPv6. No, it is a barrier to ubiquitous IPv6 adoption. ___ 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
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore mo...@network-heretics.comwrote: So the existence of 6to4 is in itself a significant barrier for IPv6 deployment for server operators and content providers. non sequitur. Existing server operators and content providers can easily provide 6to4 addresses for their servers and content, which will be used in preference to native v6 addresses. No. According to Geoff's data, one of the main reasons 6to4 fails is a firewall that blocks IPv4 protocol 41 traffic. Even if content providers published 6to4 addresses, those connections would still fail. Application developers should develop using manually configured tunnels, not 6to4. At least they don't have a 20% failure rate. How do you know? How do you even measure the failure rate of manually configured tunnels in the aggregate? In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. I don't think you can monitor that kind of traffic the way you can 6to4, because the traffic patterns are much more constrained. It's been awhile since I used manually configured tunnels (from a well-known tunnel broker). But the one time I did try them, 6to4 worked better overall - lower latency and lower failure rate. Please try again. You will be pleasantly surprised. ___ 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
On Thu, Jun 9, 2011 at 11:37 AM, Keith Moore mo...@network-heretics.comwrote: I suppose we should just tunnel the whole IPv6 network over IPv4 + HTTP then. Seriously, the argument that 6to4 should be trashed because ISPs are blocking tunnels has the flavor of don't solve the problem, but rather, stamp out the solution. Actually, this mostly happens in enterprise networks and universities. I don't see why they would want to change this compared to, say, actually deploying native IPv6. In a similar way as Geoff measured 6to4 - looking at SYNs. From where? Again, the tunnels aren't taking the variety of paths that 6to4 connections are. It's that variety that makes measurements such as Geoff's at all useful - it's what lets you at least believe that the measurements made at a few points are representative of the whole. From the same place that he ran the 6to4 measurements from? A few months ago I was trying to set one up, but I ran out of time. I'm really busy these days, and it's nowhere nearly as easy to set up a configured tunnel as it is to set up 6to4. Go to http://tunnelbroker.net/ . I'm willing to bet that it will take a lot less time than you have spent writing email on this thread. :-) ___ 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
On Thu, Jun 9, 2011 at 12:01 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: In a similar way as Geoff measured 6to4 - looking at SYNs. I suspect that the answer will be that much fewer users have configured tunnels than 6to4, and that the failure rate is much lower. Er, I'm currently on 2001:388:f000:: Do you have an algorithm that will tell you whether that is native or a configured tunnel? Not perfectly. But you can look at things like MSS and MTU. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
On Tue, May 31, 2011 at 6:17 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: While you have not contributed text per se (by sending it directly), I try to be a good listener and items you and other Googlers have raised have been included in the document around motivations and so on. Even new Sections 3.2 and 3.2 were added based on listening to you and/or your colleagues talk about the issue (and some direct conversations a couple of weeks ago). Sure - anything said at the IETF and on mailing lists is subject to the note well. But I wouldn't want to be seen as having contributed to the document. Regards, Lorenzo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
On Mon, May 30, 2011 at 8:48 AM, Gert Doering g...@space.net wrote: I have no idea what a v6 DNS ACL should be, except maybe an ACL that protects which IPv6 clients are allowed to talk to a DNS server. ACL is the wrong term. Saying it's an ACL makes it easy to make the argument that whoever is implementing this is denying access to a particular resource (the record). In fact, the opposite is true - by electing not to return an record, the implementer is able to allow access to a particular resource (the content that the user wants to reach) instead of publishing the resource over IPv6 where some users can't usefully reach it. Which is of course, the root of the problem here. It is the reason why many large website operators have either implemented whitelisting (Google, Facebook) or have announced that they will be implementing whitelisting (Yahoo, Akamai). And it is the reason why said website operators are not contributing to this document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli joe...@bogus.com wrote: But you've contributed to this document, so have others from that list. I don't want to contribute to the document because - in my opinion, and speaking only for myself - I don't think it can be made into a balanced assessment of the issue without major changes. Since a) I don't have even a fraction of the time I would need to actually contribute said changes, b) the document is already in an advanced state of the IETF process, and c) it doesn't matter so much what the document ends up saying, because most of the organizations for whom this is an issue have already looked at the data and recognized that they have no alternative, I was simply steering clear of the document entirely. It's true that I have pointed out things I think are incorrect. But I did not view these as contributions, more as offering occasional token opposition lest silence be interpreted as assent. :-) But perhaps you're right and I should not comment on it at all. Cheers, Lorenzo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
