Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
Before requiring IPv6 support, it is necessary to revise obviously broken parts of IPv6. For example, ICMPv6 generated agaist multicast packets should be forbidden or ICMPv6 implosions will occur. It will let ISPs filter ICMPv6, including but not limited to, those against multicast, which means PMTUD won't work. Another example is lack of guaranteed value for payload size. RFC791 specifies: The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols. and DNS just send 512B messages (520B including UDP header, which should be a mistake but is safe as no one use IPv4 options). However, there is no such size specified with IPv6, because arbitrarily lengthy header options may be inserted. Note that some header options, such as mobility ones, are inserted by IP layers without application control. Thus, applications like DNS can not specify like RFC1035: Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Masataka Ohta PS You have been warned. ___ 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
IPv6 Support Required for all IP-capable nodes draft-ietf-intarea-ipv6-required-01 The document strives to convey the message that IP is no longer equivalent to IPv4, which is a goal that I'd fully support. However, while this is a political statement that the IETF really should make, i have a large amount of scepticism that the document, as it is written, can successfully convey the message to the desired target audience. For one, i share the concerns raised by others that updating various old RFCs is not the right way to go. First, the documents technically are not in need of an update (e.g., because RFC 1812 pretty clearly states that it deals with v4 routers only). Second, changing sentences or phrases in existing documents, although not without precedent, isn't best IETF style. This is especially dubious w.r.t. RFC 4084, BCP 104. Most importantly, though, the updates to existing documents are so sophisticated and so highly likely to be overread that I'd not see anybody who managed to remain unaware until today to now follow suit. It feels a bit like giving purchase departments, or maybe even legal departments a lever to defeat claims that a product is IP capable when it indeed is IPv4 only. In that context, these two statements New IP implementations MUST support IPv6. Current IP implementations SHOULD support IPv6. appear especially interesting. What divides implementations into new and current and what's the purpose of stating requirements for current implementations, assuming an intuitive meaning of the word? I'd agree the IETF (and other I* bodies) have a point in making strong statements about IPv6 adoption, but the IETF has traditionally abstained from addressing individual false claims of RFC compliance. To that extent i do not see how this would be different for the draft in Last Call. For the really agnostic, it also isn't too helpful since RFCs 1812 and 1122 are of lesser concern. Documents like RIPE-501, although not ideal, provide much better guidance. In summary, if the core message is IP != IPv4 then i believe the text isn't crisp enough; if it were bullets for legal/purchase, i do not see the point. -Peter ___ 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
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: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
Hi George, At 10:11 22-08-2011, George, Wesley wrote: 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. Ok. 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 From where I sit I have not seen credible plans from residential broadband providers to have IPv6 enabled. Please note that my comment should not be read as a disagreement about what you said about US residential providers. 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 naught. I don't think that it should be a serial process. Although my earlier quote might not have emphasized it, doing this serially is like having a chicken and egg discussion. I am not saying don't bother. You are building the last mile and you see a problem which occurs beyond the DSLAM/BRAS. You don't want to wait for the next technology refresh cycle. I agree with you on that. I mentioned that the last mile can also be a problem (it may not be one from where you stand). 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. Thanks for the explanation. For what it is worth, I made a similar comment about another draft ( http://www.ietf.org/mail-archive/web/ietf/current/msg68520.html ). Based on what you said above, there wasn't any desire for corporate name-dropping. WEG] It would be helpful to know whether you do not support this because of the choice to update several RFCs, the choice to make it a proposed standard (instead of BCP or informational), or you disagree with the entire thing. This will make it easier for the authors to address your concerns adequately. As I mentioned in a previous message, the draft comes out as a statement about IPv6-required instead of a Proposed Standard. Irrespective of whether the document is a PS or BCP, it is important the ideas are clearly expressed. Brian mentioned that the document can be fixed with some wordsmithing. I made an attempt at send text ( http://www.ietf.org/mail-archive/web/ietf/current/msg68534.html ). I came to the conclusion that the document needs more work before being ready for a Last Call. The comment about informative v/s normative references ( http://www.ietf.org/mail-archive/web/ietf/current/msg68535.html ) was not made from a process perspective. You can label it as editorial and I am not going to dispute the decision. In the context of the document, I'll just read it as draft-ietf-6man-node-req-bis (or the existing RFC) can be overlooked. I would not support the publication as the draft as Informational in its current form as it attempts to update several Standards Track RFCs. You could try to get away with it by dropping the Updates. I agree with Tom Petch that the document comes out as utterly bizarre ( http://www.ietf.org/mail-archive/web/ietf/current/msg68536.html ). I would not say that it seriously damages the Internet. The document does not come out as a convincing argument to implement IPv6. At 12:44 22-08-2011, George, Wesley wrote: 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 The multiple permutations ends up injecting complexity and can end up making the BCP inaccessible. As much as it is part of reality, it can end up being an
Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
Hi Brian, At 16:49 20-08-2011, Brian E Carpenter wrote: I think most of your comments will be dealt with by wordsmithing, but... See comments below. It't quite clear to me, but we could spell it out: s/IP/IPv4/. That's clearer. Yes it does. It clarifies, for consumer organizations for example, the IPv6 is not additional technology but is part of any general IP service. 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. (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. Note: The above sub-section would need some more work as a host can do with one IPv6 address whereas a home user could get an IPv6 prefix. I used a /60 prefix. Some people may view a /56 as more appropriate. The sub-section could be broken into two, one for users and the other one for consumers. (h) Full Internet Connectivity. This service provides the user with both IPv4 Internet Connectivity and IPv6 Internet Connectivity. They are about the best practices that the IETF wishes were being used in the wild. Then it should be expected that there will be a wide disconnect between what the document says and what is happening in the wild. In essence, if there is no motivation to adhere to some semblance of reality, the IETF's wishes will remain best wishes. Of course - we have that problem every time we update any RFC. It is quite orthogonal to the question whether we *should* update the RFC. Most RFCs are not written for a wider audience. Yes. Because IPv4 has no address extensibility, it was impossible to update it for larger addresses. That has been known since 1981 or thereabouts. And that is probably why it did not make sense to update the IPv4 specifications to point to IPv6 specifications. In my opinion, it also does not make sense to do likewise with those old RFCs. The Abstract Section mentions that: this document deprecates the concept that an IP-capable node MAY support IPv4 _only_, and redefines an IP-capable node as one which supports either IPv6 _only_ or IPv4/IPv6 dual-stack. IPv6 node requirements are defined in RFC 4294. It's merely an informative reference in draft-ietf-intarea-ipv6-required-01. The discussion about IPV4 address pool exhaustion (Section 1) is a distraction from a definition of an IP-capable node. If the intention is to push for IPv6 support in all nodes so that an IP node is ubiquitous with IPv4 and IPv6, it would be helpful to have a clear and concise document about that. I do not view concise as saying MUST support IPv6 and be done with it. The document would state which technical specifications an IP-capable mode must support. Regards, -sm 1. http://www.6ip.cu/documentos-cuba/R140-08.pdf ___ 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
On 2011-08-21 19:02, SM wrote: Hi Brian, ... IPv6 node requirements are defined in RFC 4294. It's merely an informative reference in draft-ietf-intarea-ipv6-required-01. The discussion about IPV4 address pool exhaustion (Section 1) is a distraction from a definition of an IP-capable node. If the intention is to push for IPv6 support in all nodes so that an IP node is ubiquitous with IPv4 and IPv6, it would be helpful to have a clear and concise document about that. I do not view concise as saying MUST support IPv6 and be done with it. The document would state which technical specifications an IP-capable mode must support. That is the role of draft-ietf-6man-node-req-bis (which, if approved, will obsolete RFC 4294). There are practical reasons why both of these documents are Informational, and thefore would require special arguments to be cited normatively. Brian ___ 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
At 11:33 19-08-2011, The IESG wrote: The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'IPv6 Support Required for all IP-capable nodes' draft-ietf-intarea-ipv6-required-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-02. Exceptionally, comments may be 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? The exhaustion of IPv4 and the continued growth of the internet worldwide has created the driver for widespread IPv6 deployment. As a nit, that should be exhaustion of the IANA IPv4 global pool. 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. 'Many vendors, especially in the consumer space have continued to view IPv6 support as optional. Even today they are still selling IP capable or Internet Capable devices which are not IPv6-capable, which has continued to push out the point at which the natural hardware refresh cycle will significantly increase IPv6 support in the average home or enterprise network.' 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. Considering that I am living on an IPV6 island, let's see whether the following domains would accept my messages: icann.org ietf.org itu.int Let's push this further by sampling domains in recent RFCs: cisco.com ericsson.com alcatel-lucent.com nttv6.net juniper.net nokia.com huawei.com us.ibm.com microsoft.com orange-ftgroup.com For anyone who doesn't want the bother to figure it out, the answer is two. Even if the average home gets an IPv6-capable device, that would not get it any further due to last-mile issues. The ISP probably forgot to include RFC 2460 support as part of its requirements. Now, you can understand why they (not referring to any specific group) find it difficult to wean off 32-bit integers. For the same reason that the average consumer is not making a purchasing decision based on the presence of IPv6 support in their Internet-capable devices and services, consumers are unlikely to replace their still-functional Internet-capable devices simply to add IPv6 support - they don't know or don't care about IPv6, they simply want their devices to work as advertised. Consumers are likely to replace their still-functioning Internet-capable device if they perceive that it will help them fulfill a want. Anyway, let's get to the meat of the draft. From Section 2: 'Updates [RFC1812], especially sections 1, 2, and 4 which use the generic IP synonymously with the more specific IPv4. Since RFC1812 is an IPv4 router specification, the generic use of IP in this standard may cause confusion as IP is redefined to mean IPv4 + IPv6.' The title of RFC 1812 is Requirements for IP Version 4 Routers. The update proposed in this draft causes even more confusion as it is unclear what text is being updated in RFC 1812. '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.' This second update is again confusing as text does not get updated for example. As the intended status of this draft is Proposed Standard, there is a presumption that if it is going to update STD 3, it will do so clearly. 'Updates [RFC4084] to move Version Support from Section 4, Additional Terminology to Section 2, General Terminology. This is to reflect the idea that version support is now critical to defining the types of IP service, especially with respect to Full Internet
Re: Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
Hi Subramanian, I think most of your comments will be dealt with by wordsmithing, but... On 2011-08-21 06:11, SM wrote: ... From Section 2: 'Updates [RFC1812], especially sections 1, 2, and 4 which use the generic IP synonymously with the more specific IPv4. Since RFC1812 is an IPv4 router specification, the generic use of IP in this standard may cause confusion as IP is redefined to mean IPv4 + IPv6.' The title of RFC 1812 is Requirements for IP Version 4 Routers. The update proposed in this draft causes even more confusion as it is unclear what text is being updated in RFC 1812. It't quite clear to me, but we could spell it out: s/IP/IPv4/. '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.' This second update is again confusing as text does not get updated for example. As the intended status of this draft is Proposed Standard, there is a presumption that if it is going to update STD 3, it will do so clearly. Ditto. 'Updates [RFC4084] to move Version Support from Section 4, Additional Terminology to Section 2, General Terminology. This is to reflect the idea that version support is now critical to defining the types of IP service, especially with respect to Full Internet Connectivity. I don't consider this as a valid reason to update BCP 104. The document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. Moving version support from Section 4 to Section 2 does not make the document more helpful. Yes it does. It clarifies, for consumer organizations for example, the IPv6 is not additional technology but is part of any general IP service. I get blank stares when I ask about IP dresses. I have yet to find out what will happen when I ask about IP sex dresses. Seriously, BCPs, in general, are about what's happening in the wild and not IETF wishful thinking. They are about the best practices that the IETF wishes were being used in the wild. If you are going to take a RFC written for a wider audience and stick an Updated by into it, the reader might not see the change. Of course - we have that problem every time we update any RFC. It is quite orthogonal to the question whether we *should* update the RFC. Rather than update the existing IPv4 protocol specification standards to include IPv6, IETF has defined a completely separate set of standalone documents which cover IPv6. Was there a reason for that? Yes. Because IPv4 has no address extensibility, it was impossible to update it for larger addresses. That has been known since 1981 or thereabouts. Brian ___ 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
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. 2. section 2, page 4 reads: implementation details. Rather, it is intended to ensure that those using RFC1812 as a guideline for IP implementations understand that IP nodes SHOULD NOT support IPv4 only, and that they should use the other informative references in this document as a companion guideline for proper IPv6 implementations. suggest instead: implementation details. Rather, it is intended to ensure that those using RFC1812 as a guideline for IP implementations understand that IP nodes SHOULD support IPv6 in addition to any support provided for IPv4, and that they should use the other informative references in this document as a companion guideline for proper IPv6 implementations. reason: to me SHOULD NOT support IPv4 only seems potentially confusing. 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. Also, it's not clear what is meant by new implementations - does this mean completely new implementations, or revisions of existing implementations? Suggest that this be restated. e.g. Host and router IP implementations MUST support IPv6; to support only IPv4 is insufficient. 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. 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? At the very least, I think the MUST should be a SHOULD. Keith ___ 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
I fully support this document. It could be tuned in the way Keith suggested, but basically it is a Good Thing. Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-intarea-ipv6-required-01.txt (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'IPv6 Support Required for all IP-capable nodes' draft-ietf-intarea-ipv6-required-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-09-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document deprecates the concept that an IP-capable node MAY support IPv4 _only_, and redefines an IP-capable node as one which supports either IPv6 _only_ or IPv4/IPv6 dual-stack. This document updates RFC1812, RFC1122 and RFC4084 to reflect the change in requirements. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv6-required/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv6-required/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
