Re: Anyone see a game changer here?
When did this become slashdot? about 1996 randy
Re: Daily Industry and Government call for Commuinications infrastructure (fwd)
To all I received yesterday morning from Mr. Montaigne Marcelin, Director of Conatel the aid that has been given by Codetel to help the technicians in the Telecommunications sector: 1. 9 packs of rice 60 Kg 2. 2 packs of beans 60 Kg 3. 2 containers of oil 30 pounds each 4. 4 herring boxes 5. 354 containers of pica pica 6. 2 boxes of plastic spoon 7. 110 packs of water 8. 4 boxes of polystyrene plate 9. 2 packs of maggi 10. 1 pack of salt 11. 4 boxes of tomato pasta 12. 3 rations of bananas 13. 7 packs of spaghetti 14. 4 gallons of hot sauce The distribution of this aid is being coordinated by Napoleon Richard (509-3746-5849) an associates member of the board of AHTIC. This aid is provided to support the needy technicians families while they are making themselves available to work, Thanks to Mr. Edwin San Roman from CODETEL and all of you on the NANOG list that has been pushing for that. Regards Reynold Guerrier Treasurer AHTIC Network Engineer 509-3446-0099 On Sat, Jan 23, 2010 at 6:58 PM, Edwin S. Roman es...@indotel.gob.dowrote: Ok Enviado desde mi dispositivo BlackBerry® de Claro Dominicana -- *From: * Reynold Guerrier rey...@gmail.com *Date: *Sat, 23 Jan 2010 19:47:09 -0400 *To: *Edwin S. Romanes...@indotel.gob.do *Subject: *Re: Daily Industry and Government call for Commuinications infrastructure (fwd) See you in 1 hour. Reynold On Sat, Jan 23, 2010 at 6:48 PM, Edwin S. Roman es...@indotel.gob.dowrote: I am in the embassy Enviado desde mi dispositivo BlackBerry® de Claro Dominicana -- *From: * Reynold Guerrier rey...@gmail.com *Date: *Sat, 23 Jan 2010 19:26:32 -0400 *To: *Edwin S. Romanes...@indotel.gob.do *Subject: *Re: Daily Industry and Government call for Commuinications infrastructure (fwd) Hi Edwin I just got your message where can we meet? Reynold On Sat, Jan 23, 2010 at 3:07 PM, Edwin S. Roman es...@indotel.gob.dowrote: Reynol I am in haiti. Can you contact me Enviado desde mi dispositivo BlackBerry® de Claro Dominicana -- *From: * Reynold Guerrier rey...@gmail.com *Date: *Fri, 22 Jan 2010 19:33:46 -0400 *To: *Burton, K Josephburto...@state.gov *Cc: *Edwin S. Romanes...@indotel.gob.do; Steven G. Huter sghu...@nsrc.org; Lett, Steven Wlet...@state.gov; Garrity, Wendy SMaj USMC USSOUTHCOM/SC-ES (L)wendy.garr...@hq.southcom.mil; McLaughlin,Anydrew J.andrew_j._mclaugh...@ostp.eop.gov; Ferguson, David (ODP/OD)dfergu...@usaid.gov; Huang, Zheng (ODP/OD) zhu...@usaid.gov; Ross,Alec Jros...@state.gov; Vint Cerf v...@google.com; Jose Dominguezj...@ns.uoregon.edu *Subject: *Re: Daily Industry and Government call for Commuinications infrastructure (fwd) I just got Allen on the phone one more time. He let me know that it was a problem with the power supply of this particular OC3. So they just switch to a backup one. Reynold On Fri, Jan 22, 2010 at 5:37 PM, Burton, K Joseph burto...@state.govwrote: Reynold and/or Edwin, could you please advise of what the problem is? Joe Burton, U.S. Department of State, ( Detailed to the U.S. Haiti Telecom Task Force) *From:* Reynold Guerrier [mailto:rey...@gmail.com] *Sent:* Friday, January 22, 2010 4:55 PM *To:* Edwin S. Roman *Cc:* Steven G. Huter; Burton, K Joseph; Lett, Steven W; Garrity, Wendy S Maj USMC USSOUTHCOM/SC-ES (L); McLaughlin, Anydrew J.; Ferguson, David (ODP/OD); Huang, Zheng (ODP/OD); Ross, Alec J; Vint Cerf; Jose Dominguez *Subject:* Re: Daily Industry and Government call for Commuinications infrastructure (fwd) Edwin I just got Allen Bayard on the phone, he told me he is aware of the problem. He just arrived in Boutillers Hill he is in touch with Jeremy from CODETEL. He can be reached at 509-3701-. Regards Reynold On Fri, Jan 22, 2010 at 4:47 PM, Reynold Guerrier rey...@gmail.com wrote: Let me call you. Reynold On Fri, Jan 22, 2010 at 4:37 PM, Edwin S. Roman es...@indotel.gob.do wrote: Reynold : We need support urgent in Botellier. I am writing you inmediatelly with the details Edwin *From:* Reynold Guerrier [mailto:rey...@gmail.com] *Sent:* Friday, January 22, 2010 5:35 PM *To:* Edwin S. Roman *Cc:* Steven G. Huter; Burton, K Joseph; Lett, Steven W; Garrity, Wendy S Maj USMC USSOUTHCOM/SC-ES (L); McLaughlin, Anydrew J.; Ferguson, David (ODP/OD); Huang, Zheng (ODP/OD); Ross, Alec J; Vint Cerf; Jose Dominguez *Subject:* Re: Daily Industry and Government call for Commuinications infrastructure (fwd) HI Edwin I just talk to Mr. Montaigne Marcelin, he told me that the aid is being coordinated and will be distributed on Sunday. He will let me know the exact hour. Regards Reynold On Fri, Jan 22, 2010 at 4:07 PM, Edwin S. Roman es...@indotel.gob.do wrote: Dear Reynold: I am back tomorrow in Haiti, we keep in touch and coordinate the delivery of the fuel.
Re: Anyone see a game changer here?
On 1/24/10 7:48 AM, Damian Menscher wrote: On Sat, Jan 23, 2010 at 9:20 PM, Gadi Evrong...@linuxbox.org wrote: On 1/24/10 6:37 AM, Damian Menscher wrote: So... you're taking incomplete information hyped up by tech reporters operating based on leaks from people tangential to an investigation as fact, and deciding that if Google doesn't tell you the details of an ongoing criminal investigation that you'll assume they broke the law. No. I write there's incomplete information, mention what possibly happened, what alternatives exist, and ask for more data. Yes, if Google did do it, I support the move. Do you have new information to kill speculation, or should these tech reporters keep at it? Nobody who knows anything is going to say anything, as this is an ongoing criminal investigation. I'm afraid I'll have to leave you to your speculation. Fair enough. Damian -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.com/
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 22:04:31 CST, Larry Sheldon said: I remember a day when 18 was the largest number of computers that would ever be needed. First off, it was 5, not 18. :) Second, there's not much evidence that TJ Watson actually said it. http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote Third, given that IBM had already been shipping accounting units with limited plugboard programmability (the model 405) for almost a decade at that point, it's reasonable to conclude that TJ was intentionally and specifically talking about high-end if you have to ask you can't afford it systems. And if you look at the Top500 list now, 65 years years later, it's still true - there's always 2-5 boxes that are *way* out in front, then a cluster in spots 5-20 or so, and then a *really* long tail on the way down to #500. http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4006.html pgp520KJ6WSU9.pgp Description: PGP signature
Re: Using /126 for IPv6 router links
On 1/24/2010 10:03 AM, valdis.kletni...@vt.edu wrote: On Sat, 23 Jan 2010 22:04:31 CST, Larry Sheldon said: I remember a day when 18 was the largest number of computers that would ever be needed. First off, it was 5, not 18. :) Second, there's not much evidence that TJ Watson actually said it. http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote I think the 18 was a UNIVAC blunder (don't remember who supposedly said it). Given their corporate history, I can believe it, Third, given that IBM had already been shipping accounting units with limited plugboard programmability (the model 405) for almost a decade at that point, it's reasonable to conclude that TJ was intentionally and specifically talking about high-end if you have to ask you can't afford it systems. And if you look at the Top500 list now, 65 years years later, it's still true - there's always 2-5 boxes that are *way* out in front, then a cluster in spots 5-20 or so, and then a *really* long tail on the way down to #500. http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4006.html It may surprise some folks to learn that there were several computer makers--IBM was not the first, not the best, and not the stupidest. -- Government big enough to supply everything you need is big enough to take everything you have. Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Using /126 for IPv6 router links
On Jan 23, 2010, at 8:04 PM, Larry Sheldon wrote: On 1/23/2010 9:47 PM, Owen DeLong wrote: 64 bits is enough networks that if each network was an almond MM, you would be able to fill all of the great lakes with MMs before you ran out of /64s. Did somebody once say something like that about Class C addresses? The number of /24s in all of IPv4 would only cover 70 yards of a football field (in a single layer of MMs). Compared to the filling the three-dimensional full volume of all 5 great lakes, I am hoping you can see the vast difference in the comparison. Of course--I was asking about the metaphorical message implying More than we can imagine ever needing. I remember a day when 18 was the largest number of computers that would ever be needed. Do not make the mistake of assuming that just because I support using IPv6 as designed (at least for now) I am too young to remember those things myself. While I wasn't born early enough to remember the demand for 18 computers projection of T.J. Watson in the first person, I am quite familiar with the quote and the environment that fostered it. I am also familiar with the history of the internet and it's 8-bit address precursor. Yes, your point about demand expanding beyond expectation is well taken. However, I believe that the scale of the IP address space will accommodate at least a couple of orders of magnitude expansion beyond any anticipated amount of address space demand. Further, the current IPv6 addressing scheme does come with a safety valve if people like me turn out to be wrong. If we're wrong, it will only affect 1/8th of the address space and we can do something different with the other nearly 7/8ths, possibly setting a 5-10 year horizon for renumbering out of the first 1/8th into more condensed addressing schemes so that the original 1/8th isn't wastefully allocated. Finally, we come to another key difference between IPv4 and IPv6 which is one of its best features and one of the things that has created the greatest controversy among legacy IPv4 holders. There is no IPv6 globally routable unicast space which is not issued by an RIR under contract with the recipient. Unlike in IPv4 where the ability to reclaim addresses (whether abandoned, underutilized, or otherwise) is murky at best, all IPv6 addresses are subject to a nominal annual fee and a contract which allows the RIRs to maintain proper stewardship over them. If I were designing IPv6 today, would I reserve 1/2 the bits for the host address? No, I wouldn't do that. However, I do think there is benefit to a fixed-sized host field. However, the design we have is the design we have. It's too late to make fundamental changes prior to deployment. Stack implementations all have the ability to adapt to non-fixed-size networks if necessary down the road, but, for now, /64s are the best way to avoid surprises and move forward. Owen -- Government big enough to supply everything you need is big enough to take everything you have. Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Using /126 for IPv6 router links
On Sun, 24 Jan 2010 08:57:17 -0800 Owen DeLong o...@delong.com wrote: On Jan 23, 2010, at 8:04 PM, Larry Sheldon wrote: On 1/23/2010 9:47 PM, Owen DeLong wrote: 64 bits is enough networks that if each network was an almond MM, you would be able to fill all of the great lakes with MMs before you ran out of /64s. Did somebody once say something like that about Class C addresses? The number of /24s in all of IPv4 would only cover 70 yards of a football field (in a single layer of MMs). Compared to the filling the three-dimensional full volume of all 5 great lakes, I am hoping you can see the vast difference in the comparison. Of course--I was asking about the metaphorical message implying More than we can imagine ever needing. I remember a day when 18 was the largest number of computers that would ever be needed. Do not make the mistake of assuming that just because I support using IPv6 as designed (at least for now) I am too young to remember those things myself. While I wasn't born early enough to remember the demand for 18 computers projection of T.J. Watson in the first person, I am quite familiar with the quote and the environment that fostered it. I am also familiar with the history of the internet and it's 8-bit address precursor. Yes, your point about demand expanding beyond expectation is well taken. However, I believe that the scale of the IP address space will accommodate at least a couple of orders of magnitude expansion beyond any anticipated amount of address space demand. Further, the current IPv6 addressing scheme does come with a safety valve if people like me turn out to be wrong. If we're wrong, it will only affect 1/8th of the address space and we can do something different with the other nearly 7/8ths, possibly setting a 5-10 year horizon for renumbering out of the first 1/8th into more condensed addressing schemes so that the original 1/8th isn't wastefully allocated. Finally, we come to another key difference between IPv4 and IPv6 which is one of its best features and one of the things that has created the greatest controversy among legacy IPv4 holders. There is no IPv6 globally routable unicast space which is not issued by an RIR under contract with the recipient. Unlike in IPv4 where the ability to reclaim addresses (whether abandoned, underutilized, or otherwise) is murky at best, all IPv6 addresses are subject to a nominal annual fee and a contract which allows the RIRs to maintain proper stewardship over them. If I were designing IPv6 today, would I reserve 1/2 the bits for the host address? No, I wouldn't do that. Actually, from what Christian Huitema says in his IPv6: The New Internet Protocol book, the original IPv6 address size was 64 bits, derived from Steve Deering's Simple Internet Protocol proposal. IIRC, they doubled it to 128 bits to specifically have 64 bits as the host portion, to allow for autoconfiguration. However, I do think there is benefit to a fixed-sized host field. However, the design we have is the design we have. It's too late to make fundamental changes prior to deployment. Stack implementations all have the ability to adapt to non-fixed-size networks if necessary down the road, but, for now, /64s are the best way to avoid surprises and move forward. Owen -- Government big enough to supply everything you need is big enough to take everything you have. Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Using /126 for IPv6 router links
On Jan 24, 2010, at 4:45 PM, Mark Smith wrote: Actually, from what Christian Huitema says in his IPv6: The New Internet Protocol book, the original IPv6 address size was 64 bits, derived from Steve Deering's Simple Internet Protocol proposal. IIRC, they doubled it to 128 bits to specifically have 64 bits as the host portion, to allow for autoconfiguration. Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; SIPP was the heir apparent at that point. Scott and I pushed back, saying that 64 bits was too few to allow for both growth and for innovative uses of the address. We offered 128 bits as a compromise; it was accepted, albeit grudgingly. The stateless autoconfig design came later. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Best Practices - BGP community to signal transit announces.
On 23/01/2010 17:51, Patrick Tracanelli wrote: I am acting as transit for a number of ASNs, and my upstream peers do filter my announces (as they should as I understand). Absolutely. Is there any best practices or RFC which shall suggest how this community should be set up? Say, while I do standardize this community to be MY-ASN:1 or MY-ASN:65501, is there a difference? Which community numbers should be used for this purpose, if there are any best practice for this? This is a really bad idea, if you tag your customers' prefixes with a 'do transit' community, then the customer leaks, you will tag the extra prefixes, and leak via your transit too. You must filter your customers based on the data that they put into an agreed RPSL database, and then your transit provider should filter you on the same basis. Some people shuffle static prefix lists to negotiate their prefix filters. Life is too short for this though. Let computers and databases do the work for you. Andy Davidson // www.netsumo.com
Re: Using /126 for IPv6 router links
On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses (What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17? :) pgpOVQH7oENvJ.pgp Description: PGP signature
Re: Using /126 for IPv6 router links
On Jan 24, 2010, at 6:26 PM, valdis.kletni...@vt.edu wrote: On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses (What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17? :) Precisely. The two bits could feed into a simple decoder that would activate one of four address handlers; depending on your design, they could all run in parallel, with only the output of one of them used. There were only four choices, all a multiple of 8 bytes. But my goal is not to revisit the design issues, but rather to clarify the historical record. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Status as of Friday COB @ Boutillers, Port au Prince, Haiti
On Jan 23, 2010, at 8:41 AM, Eric Brunner-Williams wrote: Reginald Chauvet, the owner of the Data Center in Boutillers, in which the .ht Country Code registry is a tenant, has left Haiti with his family. All the critical telecom infrastructures are located at the Data Center in Boutillers. Note that the servers that master the .HT domain are located in Sydney, Australia, in the CoCCA datacenter, and have been (and continue to be) continuously available. The general business operations of the registry are presumably still on hold, but the .HT domain administrators and those of us operating the publicly-visible .HT servers arrived at a process for making any necessary updates to delegations and nameserver records for second-level domains quite some time ago, so there's no operational impact here. The .HT domain has been continuously functional throughout this affair. -Bill PGP.sig Description: This is a digitally signed message part
Re: Using /126 for IPv6 router links
On 24/01/2010, at 5:28 PM, Leo Bicknell wrote: In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote: I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) I have used /126's, /127's, and others, based on peers preference. I personally have a fondness for /112's, as it gives you more than 2 addresses, and a DNS bit boundary. For all the pontification about how there are enough /64's to number all the grains of sand, or other nonsense, I think that ignores too much operational information. rDNS is important, and becomes harder in IPv6. Making it easier is importnat. Having a scan of a /64 fill your P2P T1 is poor design, all because you assigned 2^64 addresses to a link that will never have more than 2 functional devices. Most importantly, we should not let any vendor code any of these into software or silicon, in case we need to change later. I too prefer /112s. I can take the first /64 in any assignment or allocation and set it aside for networking infrastructure. The first /112 is for loopbacks, the remaining /112s are for linknets. Then I can filter this /64 at my border, and it's easy. You can do the same thing with /64 linknets, but then you have to set aside a block of them, and that might get hard if you have a /48 or something. Maybe not. What if you have a /56? Maybe there is some value in linknets being effectively disposable so you never have to worry about problems coming from re-use. A single /64 full of /112s gives you 281 trillion. For links to customers and other networks, I like /64s, because they are right now the standard so you're not going to run in to compatibility problems. If you've got links to customers you should have a /32, so setting aside a /48 or a /44 or something for those customer links is no huge drama. -- Nathan Ward
Re: Using /126 for IPv6 router links
On 24/01/10 12:54, Owen DeLong wrote: Use the /64... It's OK... IPv6 was designed with that in mind. I'd suggest using a /126. For two reasons. 1) Using EUI-64 addresses on router-router links is an error, the consequences of which you encounter the first time you replace some faulty hardware.[1] I have made this error :-( If you are not using EUI-64 then assigning a non-autoconf /64 is no less or more work than assigning a non-autoconf /126. 2) Having a block of addresses for router-router links (and other blocks for other infrastructure such as loopbacks and unicast) makes ACLs much simpler. Using a /126 means that this block can last for a long, long time, reducing configuration maintenance. Cheers, Glen [1] Basically, interface addresses end up scattered through the router's configuration (some manufacturers are better than others in this regard). Tracking down all the references to an address and changing the config merely as the result of a hardware swap is painful and adds complexity at a time when it is not desired. -- Glen Turner http://www.gdt.id.au/~gdt/ Network Engineer Australia's Academic Research Network http://www.aarnet.edu.au/
Re: Using /126 for IPv6 router links
On Sun, 24 Jan 2010 18:41:18 -0500 Steven Bellovin s...@cs.columbia.edu wrote: On Jan 24, 2010, at 6:26 PM, valdis.kletni...@vt.edu wrote: On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses (What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17? :) Precisely. The two bits could feed into a simple decoder that would activate one of four address handlers; depending on your design, they could all run in parallel, with only the output of one of them used. There were only four choices, all a multiple of 8 bytes. But my goal is not to revisit the design issues, but rather to clarify the historical record. I think there's a lot of value in knowing why things are the way they are. It's common enough to see things that at face value appear to be overly complicated e.g. classes or subnets in IPv4 compared to IPX's simple, flat network numbers, or appear unrealistic or ridiculous like IPv6's 128 bit addresses. However I've found once I know the problem that was trying to be solved, and what options there were to solve it, I then usually understand why the particular solution was chosen, and most of the time agree with it. The value I got out of Christian's book was not the going through the mechanisms of IPv6, but his perspective on what options there were to solve certain options, and why the choices were made. Regards, Mark.
Re: Using /126 for IPv6 router links
On Mon, 25 Jan 2010 11:12:04 +1030 Glen Turner g...@gdt.id.au wrote: On 24/01/10 12:54, Owen DeLong wrote: Use the /64... It's OK... IPv6 was designed with that in mind. I'd suggest using a /126. For two reasons. 1) Using EUI-64 addresses on router-router links is an error, the consequences of which you encounter the first time you replace some faulty hardware.[1] I have made this error :-( If you are not using EUI-64 then assigning a non-autoconf /64 is no less or more work than assigning a non-autoconf /126. So all that's really saying is that you shouldn't use node addresses derived from link layer addresses, due to the risk of them changing when you swap out an interface, which makes sense. I don't think that argument really supports not using /64s though, as blah::1/64 and blah::2/64 would achieve that too. 2) Having a block of addresses for router-router links (and other blocks for other infrastructure such as loopbacks and unicast) makes ACLs much simpler. Using a /126 means that this block can last for a long, long time, reducing configuration maintenance. With a /48, the recommended size for an end-site, giving you 65 536 subnets, you could reserve the top quarter 16 384 subnets for your point to point links and loopbacks (or split that in half to separate loopbacks and p-to-p links), and then cover them with ACL them with blah:c000::/50, and still have 49 152 subnets for your edge/services LANs. Regards, Mark. Cheers, Glen [1] Basically, interface addresses end up scattered through the router's configuration (some manufacturers are better than others in this regard). Tracking down all the references to an address and changing the config merely as the result of a hardware swap is painful and adds complexity at a time when it is not desired. -- Glen Turner http://www.gdt.id.au/~gdt/ Network Engineer Australia's Academic Research Network http://www.aarnet.edu.au/
Re: Using /126 for IPv6 router links
During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the Big 10 design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; SIPP was the heir apparent at that point. Scott and I pushed back, saying that 64 bits was too few to allow for both growth and for innovative uses of the address. We offered 128 bits as a compromise; it was accepted, albeit grudgingly. The stateless autoconfig design came later. --Steve Bellovin, http://www.cs.columbia.edu/~smb This historical record finally made me understand why we have up to /128 prefixes with /128 addresses instead of what would suit best stateless autoconfig: up to /64 prefixes with /128 addresses. Rubens
DURZ published in root - you ready?
Figured I'd drop a note here reminding folks of the signed root zone publication timeline, which calls for L root to begin serving a 'DURZ' the week of 1/25/2010 -- which is now - depending on what timezone you're in: http://www.root-dnssec.org/2010/01/14/status-update-january-2010/ If you've not evaluated the *systemic effects* of a signed root zone in your operating environment (prepped operations and helpdesk staff, your own resolvers, etc..) I'd strongly suggest you do so ASAP. If you're not concerned because you're not signing anything - do note that 'systemic' is the operative word above, as this will impact you, whether you make any explicit changes in your environment or not. G'luck, -danny
Re: DURZ published in root - you ready?
Good point, tomorrow/today we'll start seeing what gets broken and hopefully why. Regards. Jorge On Sun, Jan 24, 2010 at 8:30 PM, Danny McPherson da...@tcb.net wrote: Figured I'd drop a note here reminding folks of the signed root zone publication timeline, which calls for L root to begin serving a 'DURZ' the week of 1/25/2010 -- which is now - depending on what timezone you're in: http://www.root-dnssec.org/2010/01/14/status-update-january-2010/ If you've not evaluated the *systemic effects* of a signed root zone in your operating environment (prepped operations and helpdesk staff, your own resolvers, etc..) I'd strongly suggest you do so ASAP. If you're not concerned because you're not signing anything - do note that 'systemic' is the operative word above, as this will impact you, whether you make any explicit changes in your environment or not. G'luck, -danny
Re: DURZ published in root - you ready?
In message 202705b1001241834l5b1911bat97ee2130f632f...@mail.gmail.com, Jorge Amodio writes: Good point, tomorrow/today we'll start seeing what gets broken and hopefully why. Regards. Jorge I don't expect to see much until the last root server (J) switches over. DNS implemententations are remarkably robust at routing around percieved damage. Week of 2010-05-03: J starts to serve DURZ Mark On Sun, Jan 24, 2010 at 8:30 PM, Danny McPherson da...@tcb.net wrote: Figured I'd drop a note here reminding folks of the signed root zone publication timeline, which calls for L root to begin serving a 'DURZ' the week of 1/25/2010 -- which is now - depending on what timezone you're in: http://www.root-dnssec.org/2010/01/14/status-update-january-2010/ If you've not evaluated the *systemic effects* of a signed root zone in your operating environment (prepped operations and helpdesk staff, your own resolvers, etc..) I'd strongly suggest you do so ASAP. If you're not concerned because you're not signing anything - do note that 'systemic' is the operative word above, as this will impact you, whether you make any explicit changes in your environment or not. G'luck, -danny -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DURZ published in root - you ready?
Danny/NANOG'ers L-Root will start serving DURZ 2010-01-27 2000 UTC. Let me know if you have any questions Mehmet Akcin ICANN/L-ROOT On 1/24/10 6:30 PM, Danny McPherson da...@tcb.net wrote: Figured I'd drop a note here reminding folks of the signed root zone publication timeline, which calls for L root to begin serving a 'DURZ' the week of 1/25/2010 -- which is now - depending on what timezone you're in: http://www.root-dnssec.org/2010/01/14/status-update-january-2010/ If you've not evaluated the *systemic effects* of a signed root zone in your operating environment (prepped operations and helpdesk staff, your own resolvers, etc..) I'd strongly suggest you do so ASAP. If you're not concerned because you're not signing anything - do note that 'systemic' is the operative word above, as this will impact you, whether you make any explicit changes in your environment or not. G'luck, -danny
Re: DURZ published in root - you ready?
On 2010-01-24, at 21:30, Danny McPherson wrote: Figured I'd drop a note here reminding folks of the signed root zone publication timeline, which calls for L root to begin serving a 'DURZ' the week of 1/25/2010 -- which is now - depending on what timezone you're in: http://www.root-dnssec.org/2010/01/14/status-update-january-2010/ We published more detailed target maintenance windows that we are aiming for in the deployment document (http://www.root-dnssec.org/wp-content/uploads/2010/01/draft-icann-dnssec-deployment-00.txt) but we'll try to make it easier to find. Here it is: o Group 1, Week beginning Mon 25 Jan 2010: L L: 2010-01-27 1800 UTC -- 2010-01-27 2000 UTC o Group 2, Week beginning Mon 08 Feb 2010: A A: 2010-02-10 1700 UTC -- 2010-02-10 1900 UTC o Group 3, Week beginning Mon 01 Mar 2010: M, I M: 2010-03-03 0400 UTC -- 2010-03-03 0600 UTC I: 2010-03-03 1500 UTC -- 2010-03-03 1800 UTC o Group 4, Week beginning Mon 22 Mar 2010: D, K, E D: 2010-03-24 1400 UTC -- 2010-03-24 1500 UTC K: 2010-03-24 1500 UTC -- 2010-03-24 1700 UTC E: 2010-03-24 1800 UTC -- 2010-03-24 2000 UTC o Group 5, Week beginning Mon 12 Apr 2010: B, H, C, G, F H: 2010-04-14 1400 UTC -- 2010-04-14 1500 UTC C: 2010-04-14 1500 UTC -- 2010-04-14 1700 UTC G: 2010-04-14 1700 UTC -- 2010-04-14 1900 UTC B: 2010-04-14 1900 UTC -- 2010-04-14 2100 UTC F: 2010-04-14 2100 UTC -- 2010-04-15 UTC o Group 6, Week beginning Mon 03 May 2010: J J: 2010-05-05 1700 UTC -- 2010-05-05 1900 UTC Joe
Re: Using /126 for IPv6 router links
On Jan 24, 2010, at 4:29 PM, Nathan Ward wrote: On 24/01/2010, at 5:28 PM, Leo Bicknell wrote: In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote: I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) I have used /126's, /127's, and others, based on peers preference. I personally have a fondness for /112's, as it gives you more than 2 addresses, and a DNS bit boundary. For all the pontification about how there are enough /64's to number all the grains of sand, or other nonsense, I think that ignores too much operational information. rDNS is important, and becomes harder in IPv6. Making it easier is importnat. Having a scan of a /64 fill your P2P T1 is poor design, all because you assigned 2^64 addresses to a link that will never have more than 2 functional devices. Most importantly, we should not let any vendor code any of these into software or silicon, in case we need to change later. I too prefer /112s. I can take the first /64 in any assignment or allocation and set it aside for networking infrastructure. The first /112 is for loopbacks, the remaining /112s are for linknets. Then I can filter this /64 at my border, and it's easy. You can do the same thing with /64 linknets, but then you have to set aside a block of them, and that might get hard if you have a /48 or something. Maybe not. What if you have a /56? If you have link nets, you probably shouldn't have just a /48 and you CERTAINLY shouldn't have just a /56. Owen
