Connectivity in Jonestown, TX
My brother is looking for 1 to 2mbps of connectivity in Jonestown, TX. He promises not to drink the kool-aid. Wireless links, licensed or unlicensed spectrum are acceptable, as well as leased line. Please reply to us off-list; I will summarize on the off chance that someone else is interested. matt ghali [EMAIL PROTECTED]darwin The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 09:07:47AM +0200, Pekka Savola wrote: And even if all active ASses would immediately adopt IPv6, we would land at about 18k IPv6 routes. big deal. And I don't see multihoming adoption in IPv6 being anywhere quicker than in IPv4, so: where is the problem, please? We'll have about 1 route per ASN... so even when exhausting the 16bit ASN space, this will be only 65k routes. And when will this be, extrapolating active ASN growth? 2010? 2015? Call me a retarded idiot, but I have a really hard time seeing any _practicle_ problem with 1 ASN == 1 IPv6 prefix at all. We'll run out of 16-bit ASN space much faster, and have to transition to 32-bit ASNs. Otherwise, by making the policies a bit stricter, we might make do with 16 bit ASNs, or at least make do with them much longer. My preference lies in making the policies a lot stricter, and actively verifying current delegations. I see a lot of ASN's requested just for fun with no real motive behind it. Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix. -- Cliff Albert [EMAIL PROTECTED]
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
* Cliff Albert [EMAIL PROTECTED] [2004-11-28 13:13]: Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix. unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers? -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 01:21:05PM +0100, Henning Brauer wrote: * Cliff Albert [EMAIL PROTECTED] [2004-11-28 13:13]: Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix. unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers? Because they would have to _qualify_ for an ASN first. And the rules for that are sufficiently strict - you have to prove a distinct routing policy. That means either multihoming two at least two upstreams, or upstream plus peering. The shops who have only legacy PI space announced by their single static routed upstream won't qualify. Plain simple. I say: there won't be any landrush effect, as getting ASN+PI in IPv4 is today already as easy as possible, given technical justification that you need it. The convenience factor _is_ already outlawed. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
* Daniel Roesen [EMAIL PROTECTED] [2004-11-28 14:05]: On Sun, Nov 28, 2004 at 01:21:05PM +0100, Henning Brauer wrote: * Cliff Albert [EMAIL PROTECTED] [2004-11-28 13:13]: Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix. unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers? Because they would have to _qualify_ for an ASN first. And the rules for that are sufficiently strict - you have to prove a distinct routing policy. That means either multihoming two at least two upstreams, or upstream plus peering. The shops who have only legacy PI space announced by their single static routed upstream won't qualify. Plain simple. there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they? on the other hand, 1 ASN - 1 v6 prefix does not necessarily mean 1 v6 prefix - 1 ASN. might work out. The convenience factor _is_ already outlawed. true for new allocations, but there is a gigantic installed base, and making their situation worse isn't exactly helping in getting v6 deployed. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 01:21:05PM +0100, Henning Brauer wrote: * Cliff Albert [EMAIL PROTECTED] [2004-11-28 13:13]: Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix. unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers? Hummzz, I guess that was the discussion PI vs PA that went on here ? The issue was that not only ASN delegation should be more policed but that also PI delegation should be more policed. Atleast that's my point of view. As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'. However I understand your statement, but the IPv4 policy's are mostly there because you still have to support the old way. In IPv6 we can do things the new way, so why shouldn't we decide on new policies that get us to stop all issues we had with IPv4. -- Cliff Albert [EMAIL PROTECTED]
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 02:13:17PM +0100, Henning Brauer wrote: there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they? Agreed, but currently we are at no PI for anybody but ISPs. How about first solving the PI-denial problem for those who technically need it? Convenience PI holders are a different problem space as you don't have to account for routing in solving it. on the other hand, 1 ASN - 1 v6 prefix does not necessarily mean 1 v6 prefix - 1 ASN. might work out. Exactly. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
* Cliff Albert [EMAIL PROTECTED] [2004-11-28 14:22]: As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'. I snipped that because I have nothing to add... as in, I agree that care should be taken to only give out ASNs to those who are really going to use it in a sane fashion. and maybe revoked easier when they're not in use. However I understand your statement, but the IPv4 policy's are mostly there because you still have to support the old way. In IPv6 we can do things the new way, so why shouldn't we decide on new policies that get us to stop all issues we had with IPv4. we'll never see the new way if it has so big drawbacks for so many organizations that are happy with the old way. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: who gets a /32 [Re: IPV6 renumbering painless?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-11-22, at 19.29, william(at)elan.net wrote: What is bad however is that IETF instead of pursuing it as one effort has several of them including MULTI6, HIP, etc. I don't see this as really true. MUTLI is tasked with solving the problem of scalable site-multihoming for IPv6. HIP is tasked with defining the experimental protocol HIP. They are not mutually exclusive. I would actually like to argue that they are more complimentary. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQancq6arNKXTPFCVEQKD8wCfV11jFyqW1swUJyP6h0ToB8OR4N8An2NM mxR7AmAf8qKnp/E3967ge1HO =pJet -END PGP SIGNATURE-
Re: Consortium sheds light on dark fiber's potential
Greetings - The use of aliases or partial names is prohibited on the NANOG mailing list. Please see our AUP: http://www.nanog.org/aup.html We suggest that you either: 1. Configure your email agent to also insert the real name field (i.e., my.pseudonyn -- John Smith) 2. Include your .sig in each message. We thank you for your cooperation in helping to maintain the content and quality of the NANOG mailing list. Susan Harris, Ph.D. Merit Network/Univ. of Mich. On Wed, 24 Nov 2004, Vicky wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.eetimes.com/showArticle.jhtml?articleID=53700951 regards, /vicky -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBpMpOpbZvCIJx1bcRAqFmAJ96505uhm2Ipg//JLYktUm59adqsQCgi1Hh mnOxyvTt188SnRmHtU5sBo8= =cdob -END PGP SIGNATURE- !DSPAM:41a4cb5f239141807432072!
Re: who gets a /32 [Re: IPV6 renumbering painless?]
(catching up) (you missed some stuff.) On 2004-11-22, at 18.52, Paul Vixie wrote: (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) I am not convinced A6/DNAME would have solved all problems, not even all of the ones you pointed out. the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). naturally this presumed that you could add and delete ipv6 supernets from a LAN, which appeared to be the case at that time, though now with dhcp6 and static addressing making a comeback that's no longer clear. in any case there was a need for a TCP option for endpoint-renumber, which was killed in a committee somewhere (i don't know which one, or where or when.) given that ipv6 is now somewhat deployed without rapid renumbering, and that rapid renumbering could have required logic in both endpoints of every flow, but that there are now a lot of other endpoints without any such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.)
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
And v6 without PI for will not get widespread adoption. Further, ULA will become de facto PI without aggregation. Hence my believe that ULA is a bad idea, and, my recommendation that we face the reality that PI is an important thing (unless we want to replicate the v4 NAT mess). As such, I'd much rather see us develop sane PI policy than continue down the present road. So what would be a sane PI policy? Apparently you don't want ULAs becoming de facto PI without aggregation, so do you agree that we need aggregation for PI? I agree that under current technology, if we are to use those addresses as both the endpoint identifier _AND_ the routing destination, there is some need for aggregation as a basic practicality of router memory and ASIC limitations. I think the mistake was in not recognizing (and doing something about) the need to address the need to separate end-point identifier from routing information early on in the IPNG process. I don't have a solid answer on how to cope with providing what is needed in terms of portable end-point identifiers. I think at least having some way of assigning/allocating them on a renewable (and, thus, reclaimable) basis is important. I think considering geographic allocation and hoping that line up well enough with topological aggregation may be desirable. Unfortunately, in today's cooperative/competitive internet, we can't expect are even really ask that provider A and provider B both accept packets for each other across certain links and forward them. Perhaps some form of mandatory settlement transit is what is needed to make this feasible (much like the current telephone system). I don't pretend to have all the answers. However, that does not change the fact that I think the IETF lost sight of the problem in this instance. ULA is an end-run on v6 registration by the RIRs and creates virtually uncontrolled PI space. I agree that PI space is needed by a variety of organizations for a variety of reasons and should not be limited to ISPs and very large organizations. Again, I think the key to being able to really implement this is that what is needed is portable end-point identifiers which can be used at least as reliably as current IP addresses for ACLs, Tunnel End-Point identifiers, etc. I think there needs to be a separation between the End-Point identifier and the routing so that routing can be aggregated. I think v6 has no provision to address this. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpgBGNYVgCF0.pgp Description: PGP signature
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they? They shouldn't unless they need features that are available in v6 that are not available in v4. Where's the harm in this? The v6 stack provides for encapsulating v4 addresses in v6 easily enough and the v6 specs already make allowance for this. I don't see any reason we need to get such a site over to v6. on the other hand, 1 ASN - 1 v6 prefix does not necessarily mean 1 v6 prefix - 1 ASN. might work out. While I think a policy of If you qualify for an ASN, you qualify for a prefix makes sense, I do not think that the reverse makes any sense whatsoever. Just because you have or qualify for a prefix does not necessarily mean you qualify for or need an ASN. Additionally, there will be providers that grow and have multiple prefixes within a single ASN. The convenience factor _is_ already outlawed. true for new allocations, but there is a gigantic installed base, and making their situation worse isn't exactly helping in getting v6 deployed. As near as I can tell, there's very little reason for such a site to ever adopt v6 and very little reason for the world to care that they didn't. As such, I'm not sure I understand why this is a significant issue. Is there some reason it's important for these sites to go to v6 instead of using 4-to-6 address encapsulation at their border? Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgptn7D7bG04G.pgp Description: PGP signature
A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Sun, 28 Nov 2004, Paul Vixie wrote: the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). [...] Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) with a lot less protocol complexity? As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed to achieve the goal. It seems to me that actually the A6/DNAME part is a relatively simple one to achieve using current mechanisms. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
Hummzz, I guess that was the discussion PI vs PA that went on here ? The issue was that not only ASN delegation should be more policed but that also PI delegation should be more policed. Atleast that's my point of view. I think that in the current v4 policies, ASN assignment is sufficiently policed. I think that v4 ip assignment and allocation are sufficiently policed, and, at least in the ARIN RIR case, there is reason to look at reducing (slightly) the MAU for the policing of v4 prefixes. As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'. This simply isn't true. It was true several years ago, but, is not true now. (At least for ARIN. I don't know what the policies are elsewhere). However I understand your statement, but the IPv4 policy's are mostly there because you still have to support the old way. In IPv6 we can do things the new way, so why shouldn't we decide on new policies that get us to stop all issues we had with IPv4. That would be nice, but, eliminating PI space for organizations that are able to get it or have it today will NOT lead to IPv6 adoption and will not stop the issues. It will stop some issues from some perspectives, but, as far as a significant portion of the IP using world is concerned, a major issue is not being able to switch providers without incurring significant costs associated with renumbering. Another issue is not being able to attach to multiple providers and have transparent session-continuing failover between them. Today, we solve those issues in IPv4 with ASNs and PI space that is multihomed. Many of the current v6 proposals eliminate that solution. Please tell me how, under the current v6 policies, you propose to solve the above issues in v6? Thanks, Owen -- Cliff Albert [EMAIL PROTECTED] -- If it wasn't crypto-signed, it probably didn't come from me. pgpNbTuRMVKCu.pgp Description: PGP signature
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
[...] Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) with a lot less protocol complexity? only if you can tolerate short TTL's on all your 's. in the A6/DNAME model, your A6's could have long TTL's whereas your DNAME's could have short(er) ones. As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed to achieve the goal. It seems to me that actually the A6/DNAME part is a relatively simple one to achieve using current mechanisms. the other issue is multihoming. someone who got done traversing the maze of A6 and DNAME RRs that it took to find your addresses would pretty much know that you were supernetting at the LAN level and that they should use a very short timeout when connecting to each address. when someone gets back multiple 's for you, then you might be multihomed, and folks will do just what they do with multiple A's, which doesn't support rapid renumbering.
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 10:56:31AM -0800, Owen DeLong wrote: As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'. This simply isn't true. It was true several years ago, but, is not true now. (At least for ARIN. I don't know what the policies are elsewhere). I am looking from a RIPE point of view. Lately I see ISPs popping out of the ground requesting ASNs and having actually only 1 upstream (there are 2 upstreams in the routing database, but in the real world there is only 1 upstream). -- Cliff Albert [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... As I understand it: foo.blah.org. IN A6 MYISP1 ::4321:53ef MYSIP1 IN DNAME 10 prefix1.isp1.net. ::dead:beef:: Then, in ISP1's isp1.net zone file prefix1 IN DNAME 100 feed:beef:: This way, if ISP1 needed to renumber for some reason (turning in old /32 in trade for /30, for example), they could go through the following steps: prefix1 IN DNAME 200 feed:beef:: prefix1 IN DNAME 100 2314:5124:: Wait a few days for everyone to catch on to the new DNAME, then, prefix1 IN DNAME 100 2314:5124:: Voila, painless ISP renumber without substantial end-user headache. Sure, there are other issues (like bone-headed ACLs that accept/deny host based on 128 bit address), but, this at least solved part of that problem. Owen --On Sunday, November 28, 2004 8:51 PM +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Sun, 28 Nov 2004, Paul Vixie wrote: the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). [...] Isn't about the same achievable with about two or three lines of scripting (or a new zone parsing option for bind ;) with a lot less protocol complexity? As you note, A6/DNAME wasn't a panacea. A lot additional stuff is needed to achieve the goal. It seems to me that actually the A6/DNAME part is a relatively simple one to achieve using current mechanisms. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- If it wasn't crypto-signed, it probably didn't come from me. pgp9NI4V4aRpS.pgp Description: PGP signature
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
Then I think that needs to be addressed at the RIPE level. ARIN certainly made me prove that I had a unique routing policy and multiple peering connections. They wanted letters from the ISPs involved stating that yes, I had a peering (or transit) relationship with them. Owen --On Sunday, November 28, 2004 8:14 PM +0100 Cliff Albert [EMAIL PROTECTED] wrote: On Sun, Nov 28, 2004 at 10:56:31AM -0800, Owen DeLong wrote: As I also stated in my last post (which you snipped out, and is pretty relevant) is that the handing out of ASN's should be harder. Currently ASN's are given to every silly dude that says 'i want multihoming'. This simply isn't true. It was true several years ago, but, is not true now. (At least for ARIN. I don't know what the policies are elsewhere). I am looking from a RIPE point of view. Lately I see ISPs popping out of the ground requesting ASNs and having actually only 1 upstream (there are 2 upstreams in the routing database, but in the real world there is only 1 upstream). -- Cliff Albert [EMAIL PROTECTED] -- If it wasn't crypto-signed, it probably didn't come from me. pgpf0qFJPBDT7.pgp Description: PGP signature
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 08:14:12PM +0100, Cliff Albert wrote: I am looking from a RIPE point of view. Lately I see ISPs popping out of the ground requesting ASNs and having actually only 1 upstream (there are 2 upstreams in the routing database, but in the real world there is only 1 upstream). RIPE checks new ASN assignments after 6 months for evidence of adherence to the rules. I've personally seen this happen for a customer ASN. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 08:48:43PM +0100, Daniel Roesen wrote: I am looking from a RIPE point of view. Lately I see ISPs popping out of the ground requesting ASNs and having actually only 1 upstream (there are 2 upstreams in the routing database, but in the real world there is only 1 upstream). RIPE checks new ASN assignments after 6 months for evidence of adherence to the rules. I've personally seen this happen for a customer ASN. This is good, but it should also happen for ASN's that are already active. An check for active use of the ASN and conforming to the current rules every 6 months should be a nice thing. This way old unused ASN's can be recycled easilier. Probably RIPE will implement such a thing when there routing registry consistency check software is complete. -- Cliff Albert [EMAIL PROTECTED]
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On 28-nov-04, at 20:56, Cliff Albert wrote: I am looking from a RIPE point of view. Lately I see ISPs popping out of the ground requesting ASNs and having actually only 1 upstream (there are 2 upstreams in the routing database, but in the real world there is only 1 upstream). RIPE wants to see (email) contact info for two peers / upstreams. AS numbers are invariably easier than getting IP addresses. (Except IPv6 address blocks, those have the fastest turnaround of any type of request, but you have to include a network diagram.) RIPE checks new ASN assignments after 6 months for evidence of adherence to the rules. I've personally seen this happen for a customer ASN. This is good, but it should also happen for ASN's that are already active. An check for active use of the ASN and conforming to the current rules every 6 months should be a nice thing. Good luck trying to get those AS numbers back when they are ok by the rules as per the assignment, just not the current ones. This kind of stuff is why parents want their kids to go to law school. Reclaiming AS numbers is a waste of time. We need to move beyond 16 bits at some point anyway. Oh, and just for fun: tell me if you see AS12945 in your routing table. I can assure you that this AS number was assigned and is still used in full compliance with RIPE policies.
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
* Owen DeLong [EMAIL PROTECTED] [2004-11-28 19:51]: there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they? They shouldn't unless they need features that are available in v6 that are not available in v4. Where's the harm in this? The v6 stack provides for encapsulating v4 addresses in v6 easily enough and the v6 specs already make allowance for this. I don't see any reason we need to get such a site over to v6. ehm the v4-in-v6 mapping is a gigantic security issue. this is nothing but establishing tunnels automagically and extremely dangerous. v4-in-v6 is not supported on purpose or at least disabled by default on many OSes, and that is a good thing. so you say they should just keep v4 - that does not really help in getting v6 deployed. on the other hand, 1 ASN - 1 v6 prefix does not necessarily mean 1 v6 prefix - 1 ASN. might work out While I think a policy of If you qualify for an ASN, you qualify for a prefix makes sense, I do not think that the reverse makes any sense whatsoever. ack. The convenience factor _is_ already outlawed. true for new allocations, but there is a gigantic installed base, and making their situation worse isn't exactly helping in getting v6 deployed. As near as I can tell, there's very little reason for such a site to ever adopt v6 and very little reason for the world to care that they didn't. i think there's many many many more of those sites than you think. and we really don't want to run in two parallel universes for longer than it has to be... As such, I'm not sure I understand why this is a significant issue. Is there some reason it's important for these sites to go to v6 instead of using 4-to-6 address encapsulation at their border? 4-to-6 is a horrible mess. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 09:27:40PM +0100, Iljitsch van Beijnum wrote: This is good, but it should also happen for ASN's that are already active. An check for active use of the ASN and conforming to the current rules every 6 months should be a nice thing. Good luck trying to get those AS numbers back when they are ok by the rules as per the assignment, just not the current ones. This kind of stuff is why parents want their kids to go to law school. If such a check rules an ASN as 'not-ok' the owner of the ASN ofcourse always should substantiate his right for an ASN. If the owner can't provide evidence that he uses this ASN rightfully it should be revoked. Reclaiming AS numbers is a waste of time. We need to move beyond 16 bits at some point anyway. I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place. Oh, and just for fun: tell me if you see AS12945 in your routing table. I can assure you that this AS number was assigned and is still used in full compliance with RIPE policies. * 195.193.163.0/24195.69.144.12512945 I As you can see there is evidence to substantiate your claim. That you have no route: object and are advertising UUNet space under another ASN to specific peers is something else. -- Cliff Albert [EMAIL PROTECTED]
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, 28 Nov 2004, Henning Brauer wrote: * Cliff Albert [EMAIL PROTECTED] [2004-11-28 13:13]: Therefore I also agree with daniel that there is not really a problem with the 1 ASN == 1 IPv6 Prefix. unless I miss something in that proposal that means that we'll see a dramatic increase in ASNs - I mean, it is not like only organizations with an ASN assigned have v4 space now. If they have their portable address space now, why should they suddenly accept that they had to renumber when changing providers? additionally not all portable space is use by asn carrying orgs...
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On 28-nov-04, at 21:45, Cliff Albert wrote: Reclaiming AS numbers is a waste of time. We need to move beyond 16 bits at some point anyway. I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place. Well, how many AS numbers would you like to give out? 3 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively. Oh, and just for fun: tell me if you see AS12945 in your routing table. I can assure you that this AS number was assigned and is still used in full compliance with RIPE policies. * 195.193.163.0/24195.69.144.125 12945 I As you can see there is evidence to substantiate your claim. That you have no route: object and are advertising UUNet space under another ASN to specific peers is something else. This AS is only visible to around 20 peers. :-) Apparently you're one of them although I have no idea which one. The other peculiarities are to avoid taking up space in the global routing table, which would be more work but provide no benefits.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sun, 28 Nov 2004, Paul Vixie wrote: (catching up) (you missed some stuff.) eh, so must I have, atleast about multi-homing :) I'll ask below. (and yes, I'm still behind on the ipv6 reading I was supposed to do) On 2004-11-22, at 18.52, Paul Vixie wrote: (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) I am not convinced A6/DNAME would have solved all problems, not even all of the ones you pointed out. the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. This makes some sense, however, how does the client system know which address it should use? what lets the client know that the path from client-server-address-ATT is better/worse/same as the path from client-server-address-MFN or client-server-address-uu ? I would think that the 'best' solution for all parties would be 'one' address for an end system, or one path to the end system. There are all sorts of reasons, from a client side, why ipv6 seems like a huge mess, this is but one of them. It seems to me that other things like outage detection toward the provider specific addresses (uu is down and att is up, too bad I tried to get to the uu address) might also be a problem. From the server side things also seem extra-messy in v6: 1) forcing N DNS updates for each system address change (uu-forward, mfn-forward, att-forward... and reverses if you care about that as well) 2) 'extra' server resources to serve extra zones with the same information. 3) forcing urpf-like routing of traffic: uu out uu, att out att and mfn out mfn off diverse routers upstream from the local LAN. The world has been pushed toward multihoming of critical resources (critical at multiple levels) over the last 10 years, forcing extra complexity into v6 such that multihoming is now 'very difficult' (maybe not for Paul or Mr. Rosen, but for many folks still) will delay the rollout of v6 and it's acceptance. Perhaps this is just 'normal' technology acceptance process, and perhaps I'm missing a great many things in 'the v6-way', but if the multihoming can't be worked out in a sane manner I can't see rollout and acceptance of v6 coming any time soon. such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.) there are, and will be in the future, folks that WANT NAT, regardless of the perceived 'badness' of it... -Chris
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sun, Nov 28, 2004 at 11:40:59PM +0100, Iljitsch van Beijnum wrote: I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place. Well, how many AS numbers would you like to give out? 3 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively. First one should investigate how many ASN's can be recovered. If this is substantial one could probably last current ASN span till 2030. Oh, and just for fun: tell me if you see AS12945 in your routing table. I can assure you that this AS number was assigned and is still used in full compliance with RIPE policies. * 195.193.163.0/24195.69.144.125 12945 I As you can see there is evidence to substantiate your claim. That you have no route: object and are advertising UUNet space under another ASN to specific peers is something else. This AS is only visible to around 20 peers. :-) Apparently you're one of them although I have no idea which one. The other peculiarities are to avoid taking up space in the global routing table, which would be more work but provide no benefits. This has been taken from the BIT looking glass, as this is one of the peers present in the aut-num. As I said before an ASN doesn't have to appear in the global routing table, but there has to be viable evidence of the use of the ASN. -- Cliff Albert [EMAIL PROTECTED]
Re: who gets a /32 [Re: IPV6 renumbering painless?]
..., it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. ... there are, and will be in the future, folks that WANT NAT, regardless of the perceived 'badness' of it... i know. i've met some. i've been one. please join me in trying to get some of them onto the IAB so that, like prometheus, they can carry the secret of fire to those in need.
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Sun, 28 Nov 2004, Owen DeLong wrote: Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... [...] Sure. But draft-ietf-v6ops-renumbering-procedure-03.txt says it IMHO well: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. The main thrust of A6/DNAME is adding hooks for handling so-called 'rapid renumbering' and 'not-user-initiated-renumbering' scenarios. That seems unfeasible and unreasonable. Renumbering cannot be prevented. And we should take all the reasonable actions to make sure it's manageable, because otherwise we'll end up with PI/ULAs and NATs. But AFAICS, obtaining a level of 'manageability' should be sufficient. We don't necessarily want or need to solve the most tricky renumbering problems here (e.g., rapid renumbering, automatic renumbering or large sites without any actions from the administrators, etc.). To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.' -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
On Mon, 29 Nov 2004, Pekka Savola wrote: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. [Note: check spell error - draft not daft] Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. sarcasm Oh? Is that Acknolidgement the only contribution IETF has to offer in regards to renumbering? How pathetic! To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.' Is that the same as Ocean: do not cross? I guess we're lucky Columbus did not have same attitude to life as Randy... /sarcasm -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: who gets a /32 [Re: IPV6 renumbering painless?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, On 2004-11-28, at 17.47, Paul Vixie wrote: (catching up) (you missed some stuff.) Yes, I have had lot's of fun reading through almost a week of Nanog... the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. Somehow I must be confused. AFAIK DANME/A6 is/would be/could have been of great help with the name to number mapping when renumbering. But the main problem is the actual renumbering of the HOSTs. And I fail to see how A6/DNAME would help. As a matter of fact the problems that was brought to multi6 are a lot more than what you have listed A6/DNAME to address. See RFC3582 and draft-lear-multi6-things-to-think-about-03.txt for an overview. given that ipv6 is now somewhat deployed without rapid renumbering, and that rapid renumbering could have required logic in both endpoints of every flow, but that there are now a lot of other endpoints without any such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.) ULAs are not a product of multi6. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQarLg6arNKXTPFCVEQJUzgCfSgII26+xcvM8BQAb2P68UQjiR8gAnjfk xkw0hLIVRrz4RDJcxAzKksRC =z9eO -END PGP SIGNATURE-
16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Sun, 28 Nov 2004, Iljitsch van Beijnum wrote: On 28-nov-04, at 21:45, Cliff Albert wrote: Reclaiming AS numbers is a waste of time. We need to move beyond 16 bits at some point anyway. I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place. Well, how many AS numbers would you like to give out? 3 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively. Well, as I have said... having to go to 32 bit AS numbers shows that we've failed at ASN policy-making and failed at creating a scalable multihoming solution. We don't _want_ to have to give out thousands of AS numbers per month or even a year. We'd (well, I at least :) would rather that that the endsites had other means to do multihoming which wouldn't require such global resources. ASN exhaustion is IMHO just a symptom of the real problem. Enlarging the ASN space does not cure the disease, just makes it worse. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
