Re: getting IPv6 space without ARIN (Re: PAT )
Multihoming scales and is reliable and easy, if it is offered end to end by intelligent end systems, transport/application protocols on which directly handles all the multiple IP addresses from DNS (and mobility). uh, no. multihoming done by end systems has a different set of problems than multihoming done by routers. end systems have no good way to keep track of changes to network topology, and the effort and network traffic that would be required to inform them of such changes makes that approach to multihoming much less attractive. also, it is very hard to support mobility satisfactorily in this manner, especially when multiple communicating end systems are moving at the same time. Keith
Re: getting IPv6 space without ARIN (Re: PAT )
Keith; GET A CLUE. I did read the draft. Huh? You obviously don't. What's more, I have tried implementing multihoming in a way very similar to what you are describing, which is what informed my earlier comments. I know "very similar" often means "completely different", especially when you don't read the draft carefully. Without routing support from the network, it cannot be made to work well. Wrong. With the end to end principle, it is silly to distinguish routers and nodes and give routers more intelligence. With end to end multihoming, there is no reason that the global routing table is large. So, you can assume a host has full routing table. However, unless you use host route, exsitence of a route entry means that there is reachability to some part of an address range of the entry but not necessarily to the target host. Thus, routing systems may give you a hint but routing information can not be fully relied upon. All the possible addresses should be tried with certain time out. Applications needing quicker recovery should use smaller time out, of course. They are all written in the draft. READ THE DRAFT. Especially if you're also trying to support mobility. No. My draft says nothing about mobility, because it is no difficult. Masataka Ohta
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
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: getting IPv6 space without ARIN (Re: PAT )
To: [EMAIL PROTECTED] (Sean Doran) Subject: Re: getting IPv6 space without ARIN (Re: PAT ) Date: Thu, 17 Aug 2000 15:09:48 -0400 From: Thomas Narten [EMAIL PROTECTED] Sean, Spamming the ietf list is bad form. Trolling is no more appropriate. Please take this elsewhere. [...] Sean does have a habit of asking questions that highlight the fact that IPv6 isn't ready for wide-spread production deployment. I understand that you might you might not want to be reminded of this situation, but I believe that your response (particularly as an IETF area director) is inappropriate. 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. If you can point me to a production-quality Windows 98 IPv6 stack, I would be happy to try to install it on my laptop, and maybe even run it at the next IETF meeting and help you with your migration project. (Oh, and make sure wireless works.) Of course, I have been accused of being a counter-revolutionary for making these sorts of suggestions... -tjs
Re: getting IPv6 space without ARIN (Re: PAT )
Sean Doran wrote: "David R. Conrad" [EMAIL PROTECTED] writes: Only transit providers (whatever they are) should be getting v6 addresses from the registries. Since deployment seems to be based initially upon virtual topologies that are disjoint from the underlying IPv4 topology (i.e., using tunnels), surely anyone who is open to allowing other sites to connect to their virtual topology should be eligible for address space? Yes, but that doesn't *necessarily* mean a prefix short enough to be in the (hopefully small) default free table. If someone is setting up a regional virtual topology they begin to look like a metro exchange and something longer than a /29 TLA prefix might be OK. But I tend to agree with Sean. Brian
Re: getting IPv6 space without ARIN (Re: PAT )
Sean Doran wrote: Hakikur Rahman [EMAIL PROTECTED] writes: I agree with Brian Carpenter, "We expect millions of those during v6/v4 coexistence." Hakik. So back to my original question, which apparently none of the IPv6-Leaders liked: -- if we are doing tunnels which follow a logical topology rather than a physical one, -- why don't we have support for multihoming to different logical topologies We should. But multihoming is still a hard problem and we are still working on it in IPNGWG. -- with policy routing done on the host-side with respect to selecting which of various address combinations to use/allow for traffic exchanges This is part of the hard part, too complex for a short email. (I'm not trying to brush it off - it needs to get done.) -- thus allowing generalized topologically-addressed VPNs (with the topologies being virtual, constructed with tunnels) -- thus allowing a partitioning of the IPv6 address space in a way that is simultaneously both topologically aggregatable _and_ policy-based That would be good. The missing piece is the control over who gets to terminate a tunnel into a particular address space. Isn't that a business issue? Brian
Re: getting IPv6 space without ARIN (Re: PAT )
"Brian" == Brian E Carpenter [EMAIL PROTECTED] writes: Brian Sean Doran wrote: "David R. Conrad" [EMAIL PROTECTED] writes: Only transit providers (whatever they are) should be getting v6 addresses from the registries. Since deployment seems to be based initially upon virtual topologies that are disjoint from the underlying IPv4 topology (i.e., using tunnels), surely anyone who is open to allowing other sites to connect to their virtual topology should be eligible for address space? Brian Yes, but that doesn't *necessarily* mean a prefix short enough to Brian be in the (hopefully small) default free table. If someone is Brian setting up a regional virtual topology they begin to look like a Brian metro exchange and something longer than a /29 TLA prefix might be Brian OK. But I tend to agree with Sean. Bingo. That's what we (a group of interested parties, not Solidum) are looking to setup among five friendly small/medium sized ISPs that happen to share co-location space. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows fastertm Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: getting IPv6 space without ARIN (Re: PAT )
Hakikur Rahman [EMAIL PROTECTED] writes: I agree with Brian Carpenter, "We expect millions of those during v6/v4 coexistence." Hakik. So back to my original question, which apparently none of the IPv6-Leaders liked: -- if we are doing tunnels which follow a logical topology rather than a physical one, -- why don't we have support for multihoming to different logical topologies -- with policy routing done on the host-side with respect to selecting which of various address combinations to use/allow for traffic exchanges -- thus allowing generalized topologically-addressed VPNs (with the topologies being virtual, constructed with tunnels) -- thus allowing a partitioning of the IPv6 address space in a way that is simultaneously both topologically aggregatable _and_ policy-based The missing piece is the control over who gets to terminate a tunnel into a particular address space. Sean.
Re: getting IPv6 space without ARIN (Re: PAT )
"David R. Conrad" [EMAIL PROTECTED] writes: Only transit providers (whatever they are) should be getting v6 addresses from the registries. Since deployment seems to be based initially upon virtual topologies that are disjoint from the underlying IPv4 topology (i.e., using tunnels), surely anyone who is open to allowing other sites to connect to their virtual topology should be eligible for address space? Sean.
Re: getting IPv6 space without ARIN (Re: PAT )
I agree with Brian Carpenter, "We expect millions of those during v6/v4 coexistence." Hakik. Brian E Carpenter wrote: Valdis, What do you mean? Firstly "6 over 4" refers specifically to RFC 2529. Do you mean standard IPv6 tunnels as per RFC 1933 and its pending update? If so, what's the problem? We expect millions of those during v6/v4 coexistence. Why is that a swamp, assuming people get their prefixes from upstream? Brian [EMAIL PROTECTED] wrote: ... Personally, I see a major swamp of private 6-over-4 tunnels between early implementors just WAITING to happen. It;'s not bad if there's 2 or 3 or 5 sites, but it's just a tad more then O(n)... ;) Hakikur Rahman Project Coordinator SDNP-Bangladesh. Email: [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.geocities.com/hakik_2000, http://www5.50megs.com/hakik ---
Re: getting IPv6 space without ARIN (Re: PAT )
"J. Noel Chiappa" wrote: From: Daniel Senie [EMAIL PROTECTED] For all the sites in the world who'd LIKE to be able to have an upstream to provide IPv6, but for whom such doesn't exist ... some one or few organizations should look into buying a block of IPv6 space, setting up a few routers which can handle lots of tunnels, and build a virtual IPv6 upstream. ??? I thought 6to4 did basically just this - and even one single IPv4 address at the 4to6 wrapping box provides a sizeable chunk of IPv6 address space behind it (a /48, actually; enough to hold up to a fair-sized network). Well yes, but the prefix is only any use if you find a 6to4 relay router to handle your traffic (see Keith's earlier note). Brian
Re: getting IPv6 space without ARIN (Re: PAT )
"David R. Conrad" wrote: [I suspect this should probably go over to ipng or something, so this'll be my last post] Yes. You can't simply banish multihoming by fiat Wouldn't think of it (always thought the arguments that multi-homing to different providers wasn't necessary were unrealistic). But I thought the official solution to multi-homing in v6 was an (provider allocated) address per interface. I will admit I haven't been following this too closely. Which document(s) did I miss? There are multiple solutions or proto-solutions, including the ones that we use for IPv4. But it's a hard problem (not because of IPv6 particularly - it's intrinsically hard). So it is an ongoing discussion in the WG. Brian
Re: getting IPv6 space without ARIN (Re: PAT )
to be even more specific, a 6to4 prefix can only be used to communicate with other 6to4 sites unless/until you find a 6to4 relay router to handle your traffic between your site and the native IPv6 world. Seems to me that it would all be so much simpler if you got rid of native prefixes altogether and just ran everything over 6to4... PF
Re: getting IPv6 space without ARIN (Re: PAT )
Seems to me that it would all be so much simpler if you got rid of native prefixes altogether and just ran everything over 6to4... tunneling everything over IPv4 seems okay as a transition strategy (other people like it less than I do), but hardly seems like a good solution for the long term. Keith
RE: getting IPv6 space without ARIN (Re: PAT )
to be even more specific, a 6to4 prefix can only be used to communicate with other 6to4 sites unless/until you find a 6to4 relay router to handle your traffic between your site and the native IPv6 world. Seems to me that it would all be so much simpler if you got rid of native prefixes altogether and just ran everything over 6to4... PF Maybe I missed your meaning but it sounds to me like you're advocating a changeover to IPv6 WITHOUT extending the address space. Aren't we having enough trouble convincing people to look at IPv6 seriously as it is??? On another note, heck out www.6bone.com they have a nice "How to get your IPv6 address" page.
Re: getting IPv6 space without ARIN (Re: PAT )
"David R. Conrad" wrote: ... b) in the situation where I am using IPv6 instead of RFC1597, then my address can't be topologically significant. If you're using this in the context of private networks, then any set of numbers would do. Why not pick one at random? er, no. In this case you should use IPv6 site-local addresses. Please, please, nobody ever pick a prefix at random. Your prefix should *always* come from your upstream provider, up to the level of Top Level Aggregator, which comes from a registry. Brian
Re: getting IPv6 space without ARIN (Re: PAT )
Brian Carpenter writes - | Please, please, nobody ever pick a prefix at random. Why not? The chances of collision are quite small. Moreover, in the event of collision, IPv6 is supposed by design to facilitate automatic renumbering, so moving to another prefix should be easy, right? That's the hype. Also, since automatic configuration and extra addresses in hosts and routers is part of the IPv6 multihoming architecture, then surely when there *IS* a TLA from which addresses percolate down, surely the easy renumbering and ease of identifying which addresses to prefer and which to deprecate -- stuff we hear is among the great features of IPv6, incidentally -- means there is nearly no penalty for having chosen a random prefix in the first place. Therefore, shouldn't you (as an IPv6-Lover) be saying: | Your prefix should *always* come from your upstream provider "Your prefix should *eventually* come from your upstream providers, when and if you acquire them"? Or am I missing something fundamental? Sean.
Re: getting IPv6 space without ARIN (Re: PAT )
Sean Doran wrote: Brian Carpenter writes - | Please, please, nobody ever pick a prefix at random. Why not? The chances of collision are quite small. Moreover, in the event of collision, IPv6 is supposed by design to facilitate automatic renumbering, so moving to another prefix should be easy, right? That's the hype. Those who fail to learn from history... Also, since automatic configuration and extra addresses in hosts and routers is part of the IPv6 multihoming architecture, then surely when there *IS* a TLA from which addresses percolate down, surely the easy renumbering and ease of identifying which addresses to prefer and which to deprecate -- stuff we hear is among the great features of IPv6, incidentally -- means there is nearly no penalty for having chosen a random prefix in the first place. Therefore, shouldn't you (as an IPv6-Lover) be saying: | Your prefix should *always* come from your upstream provider "Your prefix should *eventually* come from your upstream providers, when and if you acquire them"? Or am I missing something fundamental? What'd be better is for SOME organization, perhaps IANA, setting up one provider-sized block of addresses for early adopters to USE. Here's where the general wisdom that we should all shift to IPv6 meets the reality that SOMEONE has to ante up and provide a way for folks to start really working with the protocol, with REAL and routable addresses. The policies and procedures as the Internet grew (policies forged by IETF, IANA and the realities of what was wrought) helped foster NAT. IP address space was treated as a scarce commodity, so people found ways to avoid wasting it. Now we're telling them to reinvest in a better way with IPv6, and there's understandable resistance to betting on it. Of course the lack of IPv6 stacks on many environments isn't helping matters either. Someone's going to have to find a way to break this logjam, or we'll be stuck with the IPv4 world and layers of NAT/NAPTs forever. Breaking this logjam won't happen at the IETF/IAB/IESG level. It'll happen through the actions of IANA, ARIN/RIPE/APNIC, and it'll happen if a large ISP decides it's the right thing for the Internet community. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
Re: getting IPv6 space without ARIN (Re: PAT )
| Your prefix should *always* come from your upstream provider "Your prefix should *eventually* come from your upstream providers, when and if you acquire them"? Or am I missing something fundamental? What'd be better is for SOME organization, perhaps IANA, setting up one provider-sized block of addresses for early adopters to USE. how about this? i will soon be submitting this to i-d editor. itojun Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: February 17, 2001 August 17, 2000 Guidelines for IPv6 local experiments draft-itojun-ipv6-local-experiment-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be February 17, 2001. Abstract The memo defines how a (IPv6-wise) disconnected network should conduct local IPv6 experiment. The document tries to give guidelines for novice IPv6 experimenters, and tries to help them from falling into common pitfalls. 1. Problem space There are potential IPv6 users who would like to perform experiments locally, in their IPv6 network disjoint from the worldwide IPv6 network at large (or 6bone). Site-local address [Hinden, 1998] could be used where appropriate. However, site-local address has several operational differences from global address (like below), and it is harder for novice users to configure site-local address right than global address. Also, due to the differences, some of the things the user learnt from local experiments may not be directly relevant when they get connected to the HAGINO Expires: February 17, 2001 [Page 1] DRAFTIPv6 local experiments August 2000 worldwide IPv6 network - it reduces usefulness of their local experiments. o Site-local addresses are "scoped" address, while global addresses are not. o Configuration must correctly identify site border routers. This is an additional requirement. o There are proposals on scoped routing exist [Deering, 2000] , however, implementation status is still rather disappointing. For experiments over single link, link-local address could be used. However, again, link-local address is a scoped address, and has radical operational differences from global IPv6 (or IPv4) address. 2. Recommendations First of all, do not cook up IPv6 prefix on your own. You cannot pick random prefix number, that can jeopadize the whole point of experiment. Next, it is recommended to use global addresses for early stage of experiments. As presented in the previous section, scoped (site- local/link-local) IPv6 addresses have different operational characteritics from global IPv6 addresses. In the later stage of experients, you may want to play with scoped addresses, and try to understand how they behave. 2.1. A site with 6bone site/IPv6 ISP nearby If it is possible, try to contact nearest upstream 6bone site, or upstream ISP, to give you an IPv6 prefix. By getting IPv6 address space properly, the site will have less problem when they get conneted to the worldwide IPv6 network. The address space can (supposedly) be used for future IPv6 upstream connectivity. 2.2. A site with global IPv4 connectivity Whenever the site has a global IPv4 address with it, the site should use the 6to4 IPv6 address prefix [Carpenter, 2000] derived from the IPv4 address space, for local experiments. The prefix will be 2002:xxyy:zzuu::/48, where "xxyy:zzuu" is a hexadecimal notation of an IPv4 global address that belongs to the site. For detailed discussion, please refer to 6to4 document. 2.3. Completely disconnected site If the site has no permanent global IPv4 address with it (like dialup customer site), the site has two choices. HAGINO Expires: February 17, 2001 [Page 2] DRAFTIPv6 local experiments August 2000 o The site may use site local address space. The operation needs great care as presented above. o The site may use the address prefix: 3ffe:0501:::/48. The address prefix was curved out from WIDE 6bone prefix. The site MUST be
Re: getting IPv6 space without ARIN (Re: PAT )
What'd be better is for SOME organization, perhaps IANA, setting up one provider-sized block of addresses for early adopters to USE. Hey, great idea! RFC 2471: This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. Those who fail to learn from history... Or from the present ...
Re: getting IPv6 space without ARIN (Re: PAT )
Itojun - | First of all, do not cook up IPv6 prefix on your own. You cannot pick | random prefix number, that can jeopadize the whole point of experiment. Could you expand on that please? So far, I see from Matt Crawford a single reason (IP6.INT coordination), and that at least should be in the draft, but I personally would be interested in what the objections to a random selection of a global address really are. An aesthetic argument is fine, as long as it's an explanation of how it "jeapordizes the whole point of experiment". If it is possible, try to contact nearest upstream 6bone site, or upstream ISP, to give you an IPv6 prefix How does one evaluate the nearness of a 6bone site or ISP, so that one can determine which is nearest? What if the nearest is uncooperative? Sean.
Re: getting IPv6 space without ARIN (Re: PAT )
Daniel Senie [EMAIL PROTECTED] said: Of course the lack of IPv6 stacks on many environments isn't helping matters either. B.t.w., does anybody know of a good (up-to-date) source of information that lists available IPv6 stack implementations (which environments, what quality of implementation, etc.)? Same for dual stacks? And what DNS server software supports IPv6 address records? I checked the IPNG working group site (http://www.ietf.org/html.charters/ipngwg-charter.html), but couldn't find anything that specific, probably because it is not the kind of information one will find in an Internet draft or an RFC. Bertrand Ibrahim. [EMAIL PROTECTED] http://cui.unige.ch/eao/www/Bertrand.html
Re: [Fwd: Re: getting IPv6 space without ARIN (Re: PAT )]
| Please, please, nobody ever pick a prefix at random. For one reason (of several), who's going to delegate you the reverse DNS (ip6.arpa) space to go with it? ?? The discussion was about non-transit provider (what that is) addresses that aren't connected to the (IPv6) Internet. I'm missing something obvious here. Rgds, -drc
Re: getting IPv6 space without ARIN (Re: PAT )
Sean, Spamming the ietf list is bad form. Trolling is no more appropriate. Please take this elsewhere. Thomas [EMAIL PROTECTED] (Sean Doran) writes: Brian Carpenter writes - | Please, please, nobody ever pick a prefix at random. Why not? The chances of collision are quite small. Moreover, in the event of collision, IPv6 is supposed by design to facilitate automatic renumbering, so moving to another prefix should be easy, right? That's the hype. Also, since automatic configuration and extra addresses in hosts and routers is part of the IPv6 multihoming architecture, then surely when there *IS* a TLA from which addresses percolate down, surely the easy renumbering and ease of identifying which addresses to prefer and which to deprecate -- stuff we hear is among the great features of IPv6, incidentally -- means there is nearly no penalty for having chosen a random prefix in the first place. Therefore, shouldn't you (as an IPv6-Lover) be saying: | Your prefix should *always* come from your upstream provider "Your prefix should *eventually* come from your upstream providers, when and if you acquire them"? Or am I missing something fundamental? Sean.
Re: getting IPv6 space without ARIN (Re: PAT )
http://playground.sun.com/pub/ipng/html/ipng-implementations.html Not 100% up to date of course. It will only get better. Brian [EMAIL PROTECTED] wrote: Daniel Senie [EMAIL PROTECTED] said: Of course the lack of IPv6 stacks on many environments isn't helping matters either. B.t.w., does anybody know of a good (up-to-date) source of information that lists available IPv6 stack implementations (which environments, what quality of implementation, etc.)? Same for dual stacks? And what DNS server software supports IPv6 address records? I checked the IPNG working group site (http://www.ietf.org/html.charters/ipngwg-charter.html), but couldn't find anything that specific, probably because it is not the kind of information one will find in an Internet draft or an RFC. Bertrand Ibrahim. [EMAIL PROTECTED] http://cui.unige.ch/eao/www/Bertrand.html
Re: getting IPv6 space without ARIN (Re: PAT )
Bertrand, And what DNS server software supports IPv6 address records? See http://www.isc.org/products/BIND/bind9.html (the only server I know of that supports A6, I'd be very happy to hear of another so we can do interop testing). Rgds, -drc
Re: getting IPv6 space without ARIN (Re: PAT )
On Thu, 17 Aug 2000 15:09:48 EDT, Thomas Narten said: Trolling is no more appropriate. [EMAIL PROTECTED] (Sean Doran) writes: "Your prefix should *eventually* come from your upstream providers, when and if you acquire them"? Or am I missing something fundamental? Odd.. I didn't read it as a troll. I read it as Sean asking Brian to explain exactly how the "then the magic happens" part of prefix allocation is supposed to happen. Personally, I see a major swamp of private 6-over-4 tunnels between early implementors just WAITING to happen. It;'s not bad if there's 2 or 3 or 5 sites, but it's just a tad more then O(n)... ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: getting IPv6 space without ARIN (Re: PAT )
At the risk of having an Internet AD accuse me of SPAMming or trolling... "David R. Conrad" [EMAIL PROTECTED] writes: As Brian said, get address space from your upstream provider. If your provider doesn't support v6, find another. If you can't find another then get used to and deal with the fact that you will have to renumber Here's what I am lost with. I thought that when one connects to an IPv6 provider, one's border router automatically acquires a range of addresses from that provider, which it then parcels out to other internal routers and/or hosts. That is, _number acquisition_ is fully automatic. Moreover, as noted in [SELECT] IPv6 hosts and routers can have multiple addresses per interface, thus allowing any new prefix to coexist with the old one. The trick is to make sure that the (source,destination) tuple chosen for a conversation is selected optimally. It was asserted to me very vigorously in Pittsburgh that the border router could instruct "inside" hosts routers to deprecate or prefer addresses, depending on topology, effectively as a tool to control routing policy decisions made on end systems. Ignoring the problems of an explosive number of per-interface addresses, highly complicated [SELECT] policies, the difficulty of helping hosts optimize their routing decisions, and having sessions survive the disappearance of direct connectivity to a v6 upstream, or having subnets deal with dynamicism, this at first glance seems to make it very simple to start testing out site v6 connectivity. "One just connects to an upstream". From time to time I run into the "you will have to renumber" comment (it's not just you David), and wonder about the validity of that, or whether my understanding of how it's supposed to work is at variance with how it really does (or will). I get flavours of that uncertainty too from various comments about acquiring addresses here and there, even from people who are v6-informed. (Indeed, that is at the root of my question about, "who cares if the addresses used by unconnected persons are random, or about the renumbering burden when the connect?") If the _acquisition_ of a range of IPv6 prefixes _ALWAYS_ matches the real-or-virtual topology, and the _acuqisition_ is automatic and non-disruptive, then IPv6 has done something very different from IPv4. In fact, the trade off here is fewer globally visible prefixes introduced in support of additional inter-entity connectivity for some scaling issues concerning the _removal_ of connectivity and more importantly the rate of change of connectivity between subnets and their topological parents. Routability is defined by service providers, not TLA allocation registries. The allocation registries merely define uniqueness, something that does not matter if you are not connecting to the Internet. ... and something which should not hurt you when you connect to the v6 Internet for the first time. Sean.
Re: getting IPv6 space without ARIN (Re: PAT )
Daniel, For all the sites in the world who'd LIKE to be able to have an upstream to provide IPv6, but for whom such doesn't exist, and probably won't for a long time, some one or few organizations should look into buying a block of IPv6 space, setting up a few routers which can handle lots of tunnels, and build a virtual IPv6 upstream. I'm sorry if I was unclear. I was speaking of IPv6 network topology when I was saying "upstream provider", regardless of whether that provider is using native IPv6 or tunnels or whatever. The ISP providing the service provider endpoint of the tunnel should allocate space to their customer, even if that customer is getting to them via a tunnel through another ISP. I'm surprised this isn't already on the service menu of those ISPs that have begun deploying IPv6... Rgds, -drc
Re: getting IPv6 space without ARIN (Re: PAT )
From: Daniel Senie [EMAIL PROTECTED] For all the sites in the world who'd LIKE to be able to have an upstream to provide IPv6, but for whom such doesn't exist ... some one or few organizations should look into buying a block of IPv6 space, setting up a few routers which can handle lots of tunnels, and build a virtual IPv6 upstream. ??? I thought 6to4 did basically just this - and even one single IPv4 address at the 4to6 wrapping box provides a sizeable chunk of IPv6 address space behind it (a /48, actually; enough to hold up to a fair-sized network). Noel
getting IPv6 space without ARIN (Re: PAT )
"David" == David R Conrad [EMAIL PROTECTED] writes: But, where do I get that chunk of IPv6 address space? From your service provider, of course. David If you (as an end user, presumably -- apologies if this is not a David correct assumption) do not get your address space from your David service provider, you will be creating the exact same swamp David problem that exists with IPv4. Only the potential size of the David swamp is many orders of magnitude larger. This is a red-herring. a) my service provider isn't IPv6 ready. I am doubtful that any of them will be for a long time as far as I can tell. I will be building a tunnels for a long time. (traceroute to wirespeed.solidum.com if you want to know who my ISP is) b) in the situation where I am using IPv6 instead of RFC1597, then my address can't be topologically significant. c) multihoming. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows fastertm Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
