Re: Deployment vs the IPv6 community's ambivalence towards large providers
On the other hand, some IPv6 advocates never stop beating the drums for IPv6 QoS, multi-homing, and so forth and how the Millennium will arrive with IPv6. I think the truth in both cases is not so simple as either minor enhancment or dawning of a new age. It is certainly regretful that there are some that go around touting IPv6 as the solution to all problems. But if you listen carefully to what many in the IPv6 community are saying, they are saying that IPv6 provides more addresses, and that that is *the* *main* *benefit*. The other changes/benefits (simplified autoconfiguration, improved mobility, tools to help with renumbering, etc.) while important, are secondary. IPv6 is only rationally justified as a modest but necessary enhancement to IPv4, I agree with this, and suspect that much of the core IPv6 community does as well. Thomas
Re: getting IPv6 space without ARIN (Re: PAT )
Sean does have a habit of asking questions that highlight the fact that IPv6 isn't ready for wide-spread production deployment. While I welcome Sean's input as a backbone operator, his long-running disdain for IPv6 is also well known. Perhaps my previous response was a bit hasty from this perspective. Saying more only invites further misinterpretation. What this thread has made clear is that there continues to be a need for more education about what IPv6 does and does not do. One of the things that inhibits the overall discussion and accentuates the gulf between the two communities, is folks claiming IPv6 does X (which it does not do, or is an *option* rather than a *requirement*) and then proceeding to begin discussion based on a faulty premise. Earlier postings assuming trivial and automatic renumbering in IPv6 are one example. Another is implying that IPv6 has a "new multihoming model" that replaces (as opposed to supplementing) the existing models used in IPv4, even in cases where the IPv4 approach would appear to work fine. (It is probably worth noting that in the case of multihoming, it is far from clear that the current approaches used in IPv4 will scale properly, hence the reason for pursuing additional approaches in IPv6). It's also worth reiterating that multihoming work in IPv6 is still an on-going effort, and more input (especially from operators is needed). I encourage interested persons to join the ipng mailing list and participate. Finally, the ietf list is really not the best place to have a serious technical discussion about IPv6 shortcomings. I know of IPv6 experts who aren't subscribed to this list. A more appropriate response might be to aggressively promote IPv4/IPv6 migration at IETF meetings. You might: o Coordinate an IPv6 migration help desk at the IETF that will help attendees upgrade their laptops to run IPv6, o Run IPv6 (only) on the desktop machines at the IETF, o Publish traffic statistics that compare the volume of IPv4 versus IPv6 usage at the IETF meetings, o Set an objective for when the IPv6 traffic is at least as great as IPv4 traffic at IETF meetings, and o Set an objective for when IETF meetings will support only IPv6. Some of these suggestions have merit, and I believe that help has been available at IETF meetings (though perhaps not well advertised) for those that want to run IPv6. (IPv6 services have been available at IETF meetings for some time -- if you have an IPv6 enabled on your laptop, it just works.) On the other hand, setting an objective for when IETF meetings support IPv6 only is unrealistic. IPv6 will take decades to completely displace IPv4. Also, the hard issues about disabling IPv4 at an IETF (which is what I interpret your suggestion of IPv6-only above to be) only works when all the end sites that IETFers communicate with are IPv6-enabled. We have little control over that. Thomas
IPv6 Traffic class field or DS field ??
Hi sorry if this old hat for you! and a really stupid question but could anyone help? I have been reading the RFC's relating to IPv6 for some insight to the replacement for the ipv4 TOS field. In rfc 2460, there is talk about a traffic class field and then in rfc 2474 it talks about a differentiated services field. Could anyone tell me which has been "accepted" and if so where I could find out more details about this particular field and the various priorities etc. as I am interested in trying to use this field for some qos mechanisms. Thanking you, rgds, Nik
Re: Deployment vs the IPv6 community's ambivalence towards large providers
Well, not really just the enlarged address space! There do exist certain other definite benefits of IPv6 like possible use of Flow Specifications in the Flow Label, decreased processing delay at routers, greater flexibility etc. This is not to say that the IPv6 is answer to all problems, but just to signify the worth of the effort of those working on it. -Rahul On the other hand, some IPv6 advocates never stop beating the drums for IPv6 QoS, multi-homing, and so forth and how the Millennium will arrive with IPv6. I think the truth in both cases is not so simple as either minor enhancment or dawning of a new age. It is certainly regretful that there are some that go around touting IPv6 as the solution to all problems. But if you listen carefully to what many in the IPv6 community are saying, they are saying that IPv6 provides more addresses, and that that is *the* *main* *benefit*. The other changes/benefits (simplified autoconfiguration, improved mobility, tools to help with renumbering, etc.) while important, are secondary. IPv6 is only rationally justified as a modest but necessary enhancement to IPv4, I agree with this, and suspect that much of the core IPv6 community does as well. Thomas
Re: Deployment vs the IPv6 community's ambivalence towards large providers
Well, not really just the enlarged address space! The enlarged address space is the *primary* benefit. While there are certainly numerous other benefits, they are arguably secondary. There do exist certain other definite benefits of IPv6 like possible use of Flow Specifications in the Flow Label, At this point in time, there is still a lack of consensus on how the Flow Label should be used. Or more specifically, there is as of yet no driving application that has led the IETF to define how the bits will be used. Thus, pointing to the Flow Label as an argument to move to IPv6 is unconvincing to most. decreased processing delay at routers, greater flexibility etc. All useful benefits. But very questionable as to whether they are significant enough *by* *themselves* to lead to adoption. That is why I consider them secondary. This is not to say that the IPv6 is answer to all problems, but just to signify the worth of the effort of those working on it. Yes indeed! A lot of folks have invested a lot of time and effort in IPv6 getting it where it is today. They deserve thanks for their efforts, and I thank them. Thomas
Re: Deployment vs the IPv6 community's ambivalence towards large providers
At 05:03 23/08/00, Rahul Banerjee wrote: Well, not really just the enlarged address space! There do exist certain other definite benefits of IPv6 like possible use of Flow Specifications in the Flow Label, decreased processing delay at routers, greater flexibility etc. This is not to say that the IPv6 is answer to all problems, but just to signify the worth of the effort of those working on it. I've tried really hard to avoid this debate, because it is the wrong forum and it hasn't been a particularly useful debate. The signal to noise ratio has been remarkably poor. The erroneous information quoted above is part of the frustration of the folks, like me, who aren't zealots either way and are just trying to grow The Internet. Equally erroneous information emanates regularly from certain anti-IPv6 zealots, so there are no saints here, only sinners. However, I've written code for no less than 3 IPv6 implementations, thus far, so I like to think that I'm plausibly well informed. Point by point: - Until a spec exists that explains how to actually use the Flow Label (and implement that use in Verilog or software), it is NOT a "definite benefit of IPv6". It is a *potential* *future* benefit of IPv6, but is not a "definite benefit" at present. - Other than cisco, most router vendors implement their IP forwarding in hardware, so the forwarding latency for IPv6 is really identical to that for IPv4. In the near term, many vendors have ASICs to forward IPv4 but rely on conventional CPUs and software to forward IPv6 -- in this situation IPv6 forwarding is HIGHER latency than IPv4. In the narrow case where a vendor uses software-based forwarding for both IPv4 and IPv6, it is highly implementation-dependent which, if either, is lower latency. - Greater flexibility. Too vague a claim to evaluate either way. I think it would be helpful if the advocates toned down their marketing AND if the anti-IPv6 zealots toned down their anti-marketing. Neither is helpful, IMHO. It would be useful if people on either side could have a calm discussion about reality over a meal or beverages. The last time I was present at such, the results were decidedly mixed. Sigh. Ran [EMAIL PROTECTED]
Re: getting IPv6 space without ARIN (Re: PAT )
The difference between IPv6 and IPv4 is like 4 wheels versus 3 wheels. We need the extra address space (the 4 th wheel), no brainer. What kind of suspension and brakes we need for a smoother ride are the issues to be worked. So let us get on with it and solve the problems. Nara Kamath On Wed, 23 August 2000, Thomas Narten wrote: Sean does have a habit of asking questions that highlight the fact that IPv6 isn't ready for wide-spread production deployment. While I welcome Sean's input as a backbone operator, his long-running disdain for IPv6 is also well known. Perhaps my previous response was a bit hasty from this perspective. Saying more only invites further misinterpretation. What this thread has made clear is that there continues to be a need for more education about what IPv6 does and does not do. One of the things that inhibits the overall discussion and accentuates the gulf between the two communities, is folks claiming IPv6 does X (which it does not do, or is an *option* rather than a *requirement*) and then proceeding to begin discussion based on a faulty premise. Earlier postings assuming trivial and automatic renumbering in IPv6 are one example. Another is implying that IPv6 has a "new multihoming model" that replaces (as opposed to supplementing) the existing models used in IPv4, even in cases where the IPv4 approach would appear to work fine. (It is probably worth noting that in the case of multihoming, it is far from clear that the current approaches used in IPv4 will scale properly, hence the reason for pursuing additional approaches in IPv6). It's also worth reiterating that multihoming work in IPv6 is still an on-going effort, and more input (especially from operators is needed). I encourage interested persons to join the ipng mailing list and participate. Finally, the ietf list is really not the best place to have a serious technical discussion about IPv6 shortcomings. I know of IPv6 experts who aren't subscribed to this list. A more appropriate response might be to aggressively promote IPv4/IPv6 migration at IETF meetings. You might: oCoordinate an IPv6 migration help desk at the IETF that will help attendees upgrade their laptops to run IPv6, oRun IPv6 (only) on the desktop machines at the IETF, oPublish traffic statistics that compare the volume of IPv4 versus IPv6 usage at the IETF meetings, oSet an objective for when the IPv6 traffic is at least as great as IPv4 traffic at IETF meetings, and oSet an objective for when IETF meetings will support only IPv6. Some of these suggestions have merit, and I believe that help has been available at IETF meetings (though perhaps not well advertised) for those that want to run IPv6. (IPv6 services have been available at IETF meetings for some time -- if you have an IPv6 enabled on your laptop, it just works.) On the other hand, setting an objective for when IETF meetings support IPv6 only is unrealistic. IPv6 will take decades to completely displace IPv4. Also, the hard issues about disabling IPv4 at an IETF (which is what I interpret your suggestion of IPv6-only above to be) only works when all the end sites that IETFers communicate with are IPv6-enabled. We have little control over that. Thomas
Re: Regarding SNMP
Hi See UCD SNMP web site. http://ucd-snmp.ucdavis.edu/ -Rizwan. Hi !! I wish to write an SNMP Agent which can be portable to both Linux as well as Windows NT side. Can I get open source for the same? This agent would be extension agent type. Please convey me if any such source is available. Thank you Ajay ___ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot.
Re: Deployment vs the IPv6 community's ambivalence towards large providerss
Vint; I hope I will be forgiven for adding another message to this long thread. 1. we have to discuss the practical problems of deploying IPv6 and especially a bunch of corner cases or it won't work. 2. there are still a lot of "holes" in my opinion that need filling in any credible deployment scenario - and we'll learn the most from trying to get serious, operational IPv6 networks up and running. That's an easier half of the problem. When I visited a major router vendor in last June and asked about IPv6 support, the answer was that it will be supported IPv6 at the end of next year, because it involves a lot of software work, even though their hardware is ready. They, then, asked me which of the complex feaures of IPv6, such as tunneling or NAT-like capability, should be supported. 3. the ietf general list is probably the wrong place for further extended discusssion Maybe. But it means that entire IETF is the wrong place. Here is a better place than IPNG WG committee list, where removal of features can not be accepted. Masataka Ohta
Re: Deployment vs the IPv6 community's ambivalence towards large providers
Thomas; The other changes/benefits (simplified autoconfiguration, improved mobility, tools to help with renumbering, etc.) while important, are secondary. Huh? Compared to IPv4 equivalent, all the three features of IPv6 are unnecessarily complex without necessary functionalities. IPv6 is only rationally justified as a modest but necessary enhancement to IPv4, I agree with this, and suspect that much of the core IPv6 community does as well. That's a silly statement. Committees add all the features considered by some a modest but necessary enhancement, of course. Masataka Ohta
