Re: Using /31 for router links
* Seth Mattinen: In the past I've always used /30's for PTP connection subnets out of old habit (i.e. Ethernet that won't take unnumbered) but now I'm considering switching to /31's in order to stretch my IPv4 space further. Has anyone else does this? Good? Bad? Bad. For some systems, such tricks work to some degree only due to lack of input validation, and you get failures down the road (ARP ceases to work, packet filters are not applied properly and other fun). And now is not the time to conserve address space. You really should do everything you can to justify additional allocations from your RIR.
Using /126 for IPv6 router links
Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.sei...@mironet.ch www.mironet.ch smime.p7s Description: S/MIME cryptographic signature
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010, Mathias Seiler wrote: So what do you think? Good? Bad? Ugly? /127 ? ;) This thread: http://www.gossamer-threads.com/lists/nsp/ipv6/20788 had a long discussion regarding this topic. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Using /126 for IPv6 router links
On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: http://www.gossamer-threads.com/lists/nsp/ipv6/20788 A couple of points for thought: 1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big. 2. A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: UC phone system for Haiti (was Katrina Response)
Hey guys, Just to add to the thread, I am helping run the LA/OC Event. We just started a google group called CRISISTELECOM right now its in alpha stage; the more expertise we have the better we can discuss how to help now and for future situations. http://groups.google.com/group/crisistelcom?hl=en http://crisiscamphaitila2.eventbrite.com/ - the LA Event We are hosting this today at UCI we hope to go 10am-10pm, and if we get enough telecom/network guys in one place, we may breakout into a separate room to discuss what we can do. -Israel Matthew Petach wrote: On Thu, Jan 21, 2010 at 6:53 PM, chaim.rie...@gmail.com wrote: We had a major turnout this past weekend here in southern cal. Shout out to the uc system and people. Yahoo is hosting a Crisis Camp to help support the Haiti relief efforts here in silicon valley tomorrow: http://crisiscamphaitisiliconvalley.eventbrite.com/ If you have some spare time, please consider bringing your laptop and coming over to help with supporting relief efforts in Haiti. Thanks! Matt (and for those not in sunnyvale, there's similar efforts going on in other cities around the globe:) http://www.colombiassh.org/site/CrisisCamp Haiti, Bogota, Colombia http://www.eventbrite.com/event/541831633 CrisisCamp Haiti, Boston http://crisiscampboulderdenver.eventbrite.com/ CrisisCamp Haiti, Boulder/Denver http://crisiscamphaitila2.eventbrite.com/ CrisisCamp Haiti, Los Angeles http://crisiscampmiami.eventbrite.com/ CrisisCamp Haiti, Miami http://crisiscampmontreal.wordpress.com/about/ CrisisCamp Haiti, Montreal http://crisiscampnola.eventbrite.com/CrisisCamp Haiti, New Orleans http://www.eventbrite.com/event/543649069 CrisisCamp Haiti, New York http://crisiscamphaitipdx.eventbrite.com/ CrisisCamp Haiti, Portland http://www.eventbrite.com/event/542966026/?ref=esdgCrisisCamp Haiti, Seattle http://crisiscamphaitiwdc.eventbrite.com/ CrisisCamp Haiti, Washington, DC
Foundry CLI manual?
Anyone have the Foundry/Brocade CLI reference PDF they could send me? Brocade feels you should have a support contract to have a list of commands the hardware you purchased offers and I'm having difficulty with a oc12 pos module. Thanks, David
Re: 1/8 and 27/8 allocated to APNIC
Just to be technically correct: Even if you could, you wouldn't do that with 1/8 and 2/8: will need to pair up 2/8 with 3/8! On Fri, Jan 22, 2010 at 8:30 PM, Richard Barnes richard.bar...@gmail.comwrote: To echo and earlier post, what's the operational importance of assigning adjacent /8s? Are you hoping to aggregate them into a /7? --Richard On Fri, Jan 22, 2010 at 10:16 AM, William Allen Simpson william.allen.simp...@gmail.com wrote: Nick Hilliard wrote: On 22/01/2010 13:54, William Allen Simpson wrote: Why not 36 37? Random selection to ensure that no RIR can accuse IANA of bias. See David's previous post: http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ Because relying on a blog post for policy really meets everybody's definition of rationality :-( If you're assigning 2 at the same time, they should be adjacent. The dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6.
Re: Foundry CLI manual?
On Sat, Jan 23, 2010 at 10:51:57AM -0500, David Hubbard wrote: Anyone have the Foundry/Brocade CLI reference PDF they could send me? Brocade feels you should have a support contract to have a list of commands the hardware you purchased offers and I'm having difficulty with a oc12 pos module. Ironically enough the manuals themselves are accessable without a login, but the list of manuals is not. You fail to mention which product you're interested in, so I'm going to take a stab and hope that it's something current with a pos card like an MLX/XMR. If you're still rocking an old B2P622, I'd say you're in need of far more help than any manual can provide. :) http://www.foundrynet.com/services/documentation/xmr_user/current/NetIron_04100_ConfigGuide.pdf http://www.foundrynet.com/services/documentation/xmr_diag/current/NetIronXMR-MLX_04100_DiagnosticRef.pdf -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: 1/8 and 27/8 allocated to APNIC
On Jan 21, 2010, at 9:40 PM, Joe Provo wrote: On Thu, Jan 21, 2010 at 05:13:39PM -0800, George Bonser wrote: [snip] Some of that water is dirtier than the rest. I wouldn't want to be the person who gets 1.2.3.0/24 Yeah, I encountered some lovely wireless hotspots that use visit http://1.1.1.1/ to log out. Seem some vendors encourage the behavior: http://www.cisco.com/en/US/docs/wireless/controller/4.1/configuration/guide/c41users.html (as propagated by 'amerispot.com', 'vhotspot.com.au', and some vendor I forget who does a lot of marine 802.11-sat NAT service). My guess is there may actually be some liability that resides with Cisco in this regard in producing defective equipment on purpose. - Jared
Status as of Friday COB @ Boutillers, Port au Prince, Haiti
[sent to a smaller distribution yesterday evening, now to NANOG for wider information and coordination purposes, ebw] All I am looking into booking Reynold's wife and children into short-term lodging in Santo Domingo, Dominican Republic or in a nearby island. There has been some progress on an escort ground transport (to Santo Domingo, D.R.), which will allow Reynold to stay on-site and maintain a non-zero critical technical resource at the Boutilliers Data Center. There are some signs of progress on the visa and/or parole paperwork necessary to move Dominique, Nikki and Aurelia to Florida, where one of Reynold's two (US nationals) sisters live. However, soon isn't a term with a fixed date. There has been fuel resupply, with sufficient fuel to run through the weekend (sounds familiar, neh?). With respect to the other core staffers at this facility: Stéphane Bruno, administrative contact for the .ht Country Code, has left Haiti with his family. They are currently in Washington, D.C. Max Larson Henry, technical contact for the .ht Country Code, has lost one member of his immediate family, and has taken another member of his immediate family to hospital. He is not available to assist in the operation of the telecommunications and datacommunications infrastructure at Boutillers. 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. They are currently in Maimi. All the critical telecom infrastructures are located at the Data Center in Boutillers, which contains the Internet Exchange Point, is hosted in ths Data Center. There are technicians present in the environment, for whom Mr. Guerrier has coordinated their shelter, feeding and basic needs, but no other technical resources capable of operating any of the NAP/IX/relay problems, as they arise. The transport date isn't fixed, but I expect it will be within the next 48 hours. The end-to-end, PaP-to-SD time is 5 hours, road and boarder control included in the time budget. If Reynold has to provide the escort himself he will be off-site for at least twice that period, possibly as long as 48 hours, complications costed in. The nearby island routing is via air, and preferable, but has a paperwork dependency. As Rod Beckstrom will be doing a public availability in the early evening of the 27th in Washington, D.C., and I've a real job to do from time to time (for CORE), I plan to be in Washington on the 27th. If anyone wants to meet at the Beckstrom event venue [1] or near by drop me a line. Eric [1] http://blog.icann.org/2010/01/public-meet-up-with-icann%E2%80%99s-ceo-in-washington-dc-on-27th-january/ Date: 27th January 2010 17:00 to 19:00 local time Place: Buffalo Billiards, Victorian Room, 1330 19th Street, Washington DC 20036 Map: http://tinyurl.com/yakmr9t
Re: Using /31 for router links
That's a vendor specific issue. Maybe you could take it up with them and ask what year they think this is? tv - Original Message - From: Florian Weimer f...@deneb.enyo.de To: Seth Mattinen se...@rollernet.us Cc: nanOG list nanog@nanog.org Sent: Saturday, January 23, 2010 4:06 AM Subject: Re: Using /31 for router links * Seth Mattinen: In the past I've always used /30's for PTP connection subnets out of old habit (i.e. Ethernet that won't take unnumbered) but now I'm considering switching to /31's in order to stretch my IPv4 space further. Has anyone else does this? Good? Bad? Bad. For some systems, such tricks work to some degree only due to lack of input validation, and you get failures down the road (ARP ceases to work, packet filters are not applied properly and other fun). And now is not the time to conserve address space. You really should do everything you can to justify additional allocations from your RIR.
Best Practices - BGP community to signal transit announces.
Hello Nanogers, I am acting as transit for a number of ASNs, and my upstream peers do filter my announces (as they should as I understand). Therefore I am in the way to set up a community agreement with 'em asking 'em to allow my transit announces for a certain community I wil signal 'em up. Therefore, I have two doubts which I would like to share and hear out your opinions. 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? Other than that, I remember Randi Bush's thread on signaling the upstream provider with communities, where a use with caution warn was issued[1]. Therefore, is my scenario a dont in the dos and donts list of practices on signaling the upstreams? If for some reason I should avoid setting up a community for that, whats the other better way to solve it, instead of asking for all upstream providers, one-by-one to allow the transit prefix to be announced via me? I have searched for their own existing communities and, while some up peers do have an adequated community already in place for that, they wont allow me to announce prefixes in their communities, and not everyone will have a comm for that purpose. [1]http://mailman.nanog.org/pipermail/nanog/2009-November/014767.html Thanks.
Re: Using /31 for router links
Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: What about NAT, ATM cell tax, unnecessary addressing fields in PTP protocols (including your beloved HDLC), SSAP, DSAP fields not being big enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 through AAL4, PPPoE dumbell MTUs and MSS hacks? Some of those are far worse sins in my opinion. Hmm. PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP. If all those xDSL users were willing to stick V.35 cards in their PCs and use modems that put out V.35 instead of Ethernet, the whole PPPoE kludge with all of its attendant MTU issues would have been completely unnecessary. Want PPP for authentication etc? Just run straight PPP (RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU unlike Ethernet (jogging my memory, all HDLC controllers which I recall working with allowed maximum frame size up to just a little under 2^16 octets or so), and one can thus have the standard MTU of 1500 octets on that PPP link! Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 instead of goddamn Ethernet would be a true modem: a modulator/demodulator that modulates/demodulates the bits at the electrical level without caring about what's in those bits. What everyone else in this fubared world calls an xDSL modem (a black box that puts Ethernet out) is not a modem at all (i.e., total misappropriation of the term), it is actually a bastardized router! These boxes forward packets between two network interfaces: the presented Ethernet interface and the internal (often horrendously non-standard and proprietary) HDLC or ATM interface on the actual line. A device that forwards packets between two different network interfaces is by definition a router, hence what everyone calls a modem is actually a bastardized router - bastardized because its routing (packet forwarding) function is something incomprehensible. The Ethernet-to-Ethernet NAT boxes that everyone else calls routers should be called NATters or something like that, anything but a router! A true router is a box with a few AUIs and a few V.35 ports sticking out of it, running some very capable, flexible and totally user-configurable packet forwarding software stack that supports all networking models: IP routing, MAC bridging, VC cross-connect. As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? off the soapbox for the moment MS
Re: Using /31 for router links
Florian Weimer f...@deneb.enyo.de writes: Bad. For some systems, such tricks work to some degree only due to lack of input validation, and you get failures down the road (ARP ceases to work, packet filters are not applied properly and other fun). I never had any problems using Cisco to Cisco, Linux to Linux or Cisco to Linux using /31. Only problem I encountered was when a Linux based router was replaced by a Windows box (please don't ask). cheers Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jensl...@guug.de | -
Re: Using /31 for router links
Chris Costa cco...@cenic.org writes: We recently did a backbone router upgrade and the vendor surprisingly didn't support /31's. Mind dropping a name? Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jensl...@guug.de | -
Re: Foundry CLI manual?
Richard A Steenbergen r...@e-gerbil.net writes: Ironically enough the manuals themselves are accessable without a login, but the list of manuals is not. Outch. Personally I don't like when company's hides documentation or require me to register (or even get a support contract) to read the documentation. On the other hand there are several vendor that are very forthcoming vendors that even send you test equipment for free. Guess which company's I'm recommending to customers. cheers Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jensl...@guug.de | -
Re: Network Bandwidth Reporting Tool
On 22 Jan 2010, at 02:13, Isaac Conway wrote: I am curious what tools you use to generate monthly usage and billing reports This : I was thinking about writing some quick scripts to poll the router interfaces and put it to database, Mainly because organisations have different methods for managing the flow of business metrics inside the org, e.g. crm/accounting packages/policies/products, and by writing your own glue between them you can automate the human error prone stages like this : a page I can pull up and gives me the numbers (95p, cost, overage, etc.) for the past month. Copy and paste into a spreadsheet, job complete Andy
RE: Using /31 for router links
As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. Multi-PVC is used (in the context of xSLAM--CPE), for example, for delivering IPTV+DSL. 0/35 and 0/38 are just arbitrary numbers, there are plenty of other random ones like 0/33 used by major service providers. Arguably your 99.999% is way off.
Re: Using /31 for router links
[Michael Sokolov said:] *snip* but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! *snip* We've got several ADSL and SDSL circuits that carry two PVC's: 0/35 and 0/36. Covad has a product called Voice Optimized Access. I won't go into the gory details of the underlying technology, but the second PVC is utilized for voice. Essentially two separate IP networks over one physical network, one with guaranteed bandwidth (by way of vbr-rt) and QoS through Covad's network. Sincerely, Bobby Glover Director of Information Services South Valley Internet -Original Message- From: msoko...@ivan.harhan.org (Michael Sokolov) Date: Sat, 23 Jan 2010 18:52:51 To: nanog@nanog.org Subject: Re: Using /31 for router links Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: What about NAT, ATM cell tax, unnecessary addressing fields in PTP protocols (including your beloved HDLC), SSAP, DSAP fields not being big enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 through AAL4, PPPoE dumbell MTUs and MSS hacks? Some of those are far worse sins in my opinion. Hmm. PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP. If all those xDSL users were willing to stick V.35 cards in their PCs and use modems that put out V.35 instead of Ethernet, the whole PPPoE kludge with all of its attendant MTU issues would have been completely unnecessary. Want PPP for authentication etc? Just run straight PPP (RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU unlike Ethernet (jogging my memory, all HDLC controllers which I recall working with allowed maximum frame size up to just a little under 2^16 octets or so), and one can thus have the standard MTU of 1500 octets on that PPP link! Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 instead of goddamn Ethernet would be a true modem: a modulator/demodulator that modulates/demodulates the bits at the electrical level without caring about what's in those bits. What everyone else in this fubared world calls an xDSL modem (a black box that puts Ethernet out) is not a modem at all (i.e., total misappropriation of the term), it is actually a bastardized router! These boxes forward packets between two network interfaces: the presented Ethernet interface and the internal (often horrendously non-standard and proprietary) HDLC or ATM interface on the actual line. A device that forwards packets between two different network interfaces is by definition a router, hence what everyone calls a modem is actually a bastardized router - bastardized because its routing (packet forwarding) function is something incomprehensible. The Ethernet-to-Ethernet NAT boxes that everyone else calls routers should be called NATters or something like that, anything but a router! A true router is a box with a few AUIs and a few V.35 ports sticking out of it, running some very capable, flexible and totally user-configurable packet forwarding software stack that supports all networking models: IP routing, MAC bridging, VC cross-connect. As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? off the soapbox for the moment MS
Re: Using /31 for router links
* Tony Varriale: That's a vendor specific issue. Maybe you could take it up with them and ask what year they think this is? I think they support it on point-to-point media only, which seems sufficient for RFC 3021 compliance. Ethernet is a different story, unfortunately.
Re: Using /31 for router links
Michael Sokolov wrote: That is why I hate Ethernet with a passion. Ethernet should be for LANs only; using Ethernet for WANs and PTP links is the vilest invention in the entire history of data networking in my opinion. Ah, but who's to say that all PTP links are WANs? Are you really going to run an OC-48 from one router to another _in the same building_ when you need 1Gb/s between them? Have you looked at how much more that would cost? Ethernet interfaces, particularly copper, are dirt cheap. Even for MANs or WANs, the price of a pipe (plus equipment at each end) will still often be significantly lower for Ethernet than for real circuits--especially if you don't plan on using all the bandwidth all of the time. My medium of choice for PTP links (WAN) is HDLC over a synchronous serial bit stream, with a V.35 or EIA-530 interface between the router and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP header follows...). My 4.3BSD router (or I should better say gateway as that's the proper 80s/90s term) then sees a PTP interface which has no netmask at all, hence the near and far end IP addresses don't have to have any numerical relationship between them at all. No netmask, no MAC addresses, no ARP, none of that crap, just a PTP IP link. Well, it'd certainly be nice if someone would make something even cheaper than Ethernet for that purpose (which would squeeze out a few more bits of payload), but so far nobody has. It's hard to beat Ethernet on volume, and that's the main determinant of cost/price... S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Using /31 for router links
Stephen Sprunk step...@sprunk.org wrote: Ah, but who's to say that all PTP links are WANs? Are you really going to run an OC-48 from one router to another _in the same building_ when you need 1Gb/s between them? Can't say - I have never needed that much bandwidth. :) I still live in an alternate Universe where 10 Mbps coaxial Ethernet for LANs is near- infinity and 2 Mbps or so makes for a *very* sweet WAN. The facility housing the mail server from which I am sending this message is connected to the outside Inet via a 384 kbps SDSL pipe which I am using basically as ARPANET replacement - I miss the ARPANET. If I wanted a PTP link between two routers in the same building that runs at the same speed as my Ethernet (10 Mbps), I would use EIA-422 (which is rated up to 10 Mbps) and run something HDLC-based over it. Even for MANs or WANs, the price of a pipe (plus equipment at each end) will still often be significantly lower for Ethernet than for real circuits Wait a moment here. With a MAN/WAN involving wires/fiber running over public property, what one is paying for is the right to use those wires for your data, right? The wires themselves do NOT run Ethernet at the electrical level, so if you have some MAN/WAN Ethernet service, there is a black box of some kind that converts the native electrical signal format to Ethernet. Why not take that black box out of service, use it for baseball practice (Office Space style), and use the exact same wires/fiber (rented at exactly the same monthly recurring price) in its native non-Ethernet form? IOW, if you are renting dry copper / dark fiber, you have a choice to use it either through a stinky black box Ethernet converter or in the native non-Ethernet form directly, but the monthly recurring cost remains exactly the same. Well, it'd certainly be nice if someone would make something even cheaper than Ethernet for that purpose (which would squeeze out a few more bits of payload), but so far nobody has. It's hard to beat Ethernet on volume, and that's the main determinant of cost/price... But that's non-recurring equipment cost only, and at least in my case the little investment in V.35 etc hardware is a much lower cost than the price of pain and suffering with Ethernet for a purist like me. MS
Re: Foundry CLI manual?
Jens Link li...@quux.de writes: Richard A Steenbergen r...@e-gerbil.net writes: Ironically enough the manuals themselves are accessable without a login, but the list of manuals is not. Outch. Personally I don't like when company's hides documentation or require me to register (or even get a support contract) to read the documentation. Cannot agree more. It's a major drawback even with a support contract. I often use Google to search for particular features, bugs, workarounds or whatever, limiting the scope to site:somevendor.com. This naturally doesn't work with those who hide their docs. And the site internal search engines are usually a bad joke at best. Regarding Foundry, I remember they used to have public docs several years ago. But all of a sudden it was closed. Around 2003 maybe? Nowadays, Huawei is on top of my oh i hate that web site list. No useful public content whatsoever. Don't understand why they even bother putting up a web server. I appreciate that there still are serious vendors like Cisco and Juniper who don't mind making their docs public. Thanks guys! Bjørn
Re: Using /31 for router links
On 1/23/10 11:52 AM, Michael Sokolov wrote: Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 instead of goddamn Ethernet would be a true modem: a modulator/demodulator that modulates/demodulates the bits at the electrical level without caring about what's in those bits. Back in the days of Rhythms and Copper Mountain gear, Netopia had the D series routers which were actually xDSL to DSU units. Used to use them for customers who had T1 equipment (2500s, 2600s, 1600s, etc). Worked quite well. Though, I'm not sure they'd work these days, nor do I think they came in ADSL models either. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Using /31 for router links
Brielle Bruns br...@2mbit.com wrote: Back in the days of Rhythms and Copper Mountain gear, Netopia had the D series routers which were actually xDSL to DSU units. Yes, I am very familiar with them: http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/netopia/dsu.html As that page explains, they are only pseudo-DSUs though. I much much prefer a true bit-transparent DSU: http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/xsb2000.html I have also designed and built an SDSL to EIA-530 DSU of my very own: http://ifctfvax.Harhan.ORG/OpenSDSL/OSDCU/ On the latter I have the hardware (the page above has a photo of the board), but the operational software (or firmware if you will) remains to be finished. Though, I'm not sure they'd work these days, Only in the very limited geographic footpring of what used to be DSL.net - they are the last remaining semi-major operator of CM DSLAMs: http://ifctfvax.Harhan.ORG/OpenSDSL/megapath.html My big goal is to make my own DSU which I have just mentioned function as a Layer 2 converter (FRF.8 and friends) from Nokia SDSL/ATM served by Covad to HDLC. nor do I think they came in ADSL models either. I don't think anyone have *ever* used V.35 friends with ADSL - probably because those who would want V.35 (i.e., people like me) would find ADSL morally offensive. :-) MS
Re: Using /31 for router links
Michael Sokolov wrote: Wait a moment here. With a MAN/WAN involving wires/fiber running over public property, what one is paying for is the right to use those wires for your data, right? The wires themselves do NOT run Ethernet at the electrical level, so if you have some MAN/WAN Ethernet service, there is a black box of some kind that converts the native electrical signal format to Ethernet. Why not take that black box out of service, use it for baseball practice (Office Space style), and use the exact same wires/fiber (rented at exactly the same monthly recurring price) in its native non-Ethernet form? Well, I have an OC-12 upstairs that has an Overture box attached to it because: Ethernet is not tariffed and the OC-12 is. The price difference between the two was substantial (even though it's the same thing) and I was going for cheap alternate path. If they were the same price I would have probably just taken it directly. ~Seth
CRISISTELCOM2 is entry for Helping
If you replied to prior post for CRISISTELCOM .. or are new .. Please, sign up at nanog@nanog.orgCRISISTELCOM2 our entry point to assist with broad-scope telecommunication needs in disaster as CRISIS HAITI, today, and others in the future. Welcoming engineers, managers, ideas for all electronic communications which are needed and often lost in disasters. Contact signups crisistelc...@googlegroups.com for http://groups.google.com/group/crisistelcom2 This is for tech and business volunteers to help, spammers and advertisers will be banned. Ev Batey -- WA6CRE -- efba...@gmail.com CCHaitiLA a/k/a lionever...@gmail.com or efb...@cotdazr.org (805) 616-2471 Twitter.: efbatey - CCHaitiLA: http://bit.ly/6jWfkQ ASC-USC http://bit.ly/5vzKH6
Re: Anyone see a game changer here?
From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Fri Jan 22 21:16:53 201G Subject: Re: Anyone see a game changer here? From: Steven Bellovin s...@cs.columbia.edu Date: Fri, 22 Jan 2010 22:16:03 -0500 To: Bruce Williams williams.br...@gmail.com Cc: nanog@nanog.org On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote: The problem with IE is the same problem as Windows, the basic design is fundementally insecure and timely updates can't fix that. You do realize, of course, that IE is recording less than half the = security flaw rate of Firefox? (See = http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-v= ulnerability-report---firefox-leads-the-pack-at-44.php) The number of discovered bugs in any application is finite. The number of _undiscovered_ bugs in that same application, is, by definition, infinite. Statistics don't lie, but *GRIN*
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 13:50:00 + Dobbins, Roland rdobb...@arbor.net wrote: On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: http://www.gossamer-threads.com/lists/nsp/ipv6/20788 A couple of points for thought: 1.Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big. We'd better start worrying about conserving Ethernet addresses then, because they're going to run out way before IPv6 ones will. First thing we'll need to do is setup a registry so that when ever somebody throws out an Ethernet card, they write down the MAC address so that somebody else can recycle it. Secondly we'll need to get the IEEE specs changed so that any point-to-point ethernet links don't use addressing - we're wasting two addresses on each one of them. We'll also save bandwidth by not sending an extra 12 addressing bytes in each frame on 10Gbps or 40/100 Gbps links in the future. 2.A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes. That's a new bit of FUD. References? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Foundry CLI manual?
On Sat, 23 Jan 2010 21:25:28 +0100 Bjørn Mork bj...@mork.no wrote: Jens Link li...@quux.de writes: Richard A Steenbergen r...@e-gerbil.net writes: Ironically enough the manuals themselves are accessable without a login, but the list of manuals is not. Outch. Personally I don't like when company's hides documentation or require me to register (or even get a support contract) to read the documentation. Cannot agree more. It's a major drawback even with a support contract. I often use Google to search for particular features, bugs, workarounds or whatever, limiting the scope to site:somevendor.com. This naturally doesn't work with those who hide their docs. And the site internal search engines are usually a bad joke at best. Regarding Foundry, I remember they used to have public docs several years ago. But all of a sudden it was closed. Around 2003 maybe? Nowadays, Huawei is on top of my oh i hate that web site list. No useful public content whatsoever. Don't understand why they even bother putting up a web server. I appreciate that there still are serious vendors like Cisco and Juniper who don't mind making their docs public. Thanks guys! Agree. The first thing a vendor can do to have a chance of you buying their gear is to make it as easy as possible to transition to it, and that includes becoming familiar with it's CLI, and working out how much effort you'll need to spend on converting to different syntax. What's so proprietary about how to configure OSPF that it needs to be kept a secret? Bjørn
Re: Using /126 for IPv6 router links
On Jan 24, 2010, at 4:43 AM, Mark Smith wrote: That's a new bit of FUD. References? It isn't 'FUD'. redistribute connected. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 7:50 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil --Donald Knuth A couple of points for thought: 1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big. Then obviously, it's giving every molecule in every soda can an IP address that is the waste that matters. There are several orders of magnitude between the number of molecules in a soda can (~65000 times as many) as the number of additional IPs used by giving a point-to-point link a /64. When comparing the number of molecules in a soda can TO 2^64. It's like in the IPv4 world comparing a /30 to a /31. And arguing it's wasteful to give a point-to-point link a /30 since all it needs (in theory) is a /31. Near the beginning of IPv4 (before exhaustion was an issue). when at the same time standard practice was allocating /13sto users who will use at most a /20 in 10 years. Optimizing this early creates potential issues and reduces flexibility going forward. The designer/operator should not confuse design patterns that use more IP addresses than the minimum technically possible, for a block of addresses, with design selections that are gross wastes of address space -- such as assigning every molecule its own IP. IPv6 is a very large address space, so it's LARGE optimizations that matter, such as not giving every molecule its own IP. Not small optimizations that matter, such as using a /126 for a relatively small number of P-t-P links (in the grand scheme of things) versus a /64. Anyways, I would suggest reserving a /64 to each P-t-P link, and (If you prefer) set static neighbor entry for the peer (in the case of Ethernet) and configuring a /72 (smaller than what you have reserved). For the sole reason of disabling IPv6 autoconfig and neighbor discovery. Technically everything to the right of the /64 boundary is reserved for the HOST portion, and such is the design of IPv6. This allows for greater scalability than assigning a longer prefix. If that specific connection is ever to be replaced one day with a link that's _not_ point-to-point,or to be expanded, then the designer has greater flexibility: an option that does not require re-numbering the changed link. -- -J
Re: Using /126 for IPv6 router links
On Jan 24, 2010, at 6:07 AM, James Hess wrote: Then obviously, it's giving every molecule in every soda can an IP address that is the waste that matters. There are several orders of magnitude between the number of molecules in a soda can (~65000 times as many) as the number of additional IPs used by giving a point-to-point link a /64. I'm not too sure of the math behind this - and it was just one example. The gazillions of one-time-use nanomachines used to scrape away plaque in just a single patient's bloodstream, et. al., argue against needless consumption of IP addresses, IMHO. Not to mention all the smart material molecules continuously communicating with one another via NFC or somesuch in order to dynamically re-shape automobile aerodynamics and so forth. Of course, the sinkhole issue is of far greater immediate concern. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 8:08 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) a kind soul or 2 asked: How do I sign up for the v6ops mailing list? (it's actually the ipv6 wg mailing list) https://www.ietf.org/mailman/listinfo/ipv6 should get you there... -Chris
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 23:04:26 + Dobbins, Roland rdobb...@arbor.net wrote: On Jan 24, 2010, at 4:43 AM, Mark Smith wrote: That's a new bit of FUD. References? It isn't 'FUD'. redistribute connected. In my opinion it's better not to do blind redistribution. More control means less things that are unexpected or or can be forgotten. That being said, I don't understand why that's a problem, and why that problem doesn't already exist in IPv4. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 20:08:05 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) coughInternet Draft/cough No disrespect to the people who've written it, however it's a draft at this point, not an RFC. The current IP Version 6 Addressing Architecture RFC (RFC4291) says, For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format If that draft is going to go anywhere, then I would expect there also needs to be a new version of RFC4291. why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 9:03 PM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Sat, 23 Jan 2010 20:08:05 -0500 Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) coughInternet Draft/cough No disrespect to the people who've written it, however it's a draft at this point, not an RFC. absolutely. so... if it's of interest, speak up (on the v6 wg mailing list) or let the authors know. The current IP Version 6 Addressing Architecture RFC (RFC4291) says, For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format If that draft is going to go anywhere, then I would expect there also needs to be a new version of RFC4291. I believe the authors know this as well. -Chris why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris
Re: Using /126 for IPv6 router links
On Sat, Jan 23, 2010 at 5:51 PM, Dobbins, Roland rdobb...@arbor.net wrote: It isn't 'FUD'. redistribute connected. In that case, the fault would lie just as much with the unconditional redistribution policy, as the addressing scheme, which is error-prone in and of itself. No matter how you address your links or what type of equipment on your network, it's probably possible to find some configuration error that will produce poor router behavior. ... I'm not too sure of the math behind this - and it was just one example. The gazillions of one-time-use nanomachines used to scrape away plaque in just a single patient's bloodstream, et. al., argue against needless consumption of IP addresses, IMHO. Not to mention all the smart material molecules continuously The trouble is both of the examples, is they both imply something far greater than mere needless consumption of IP addresses in and of themselves. Assigning global IP addresses to individual nanonites is a massive waste in and of itself. It is easy to logically reject needlessly assigning each nanonite as an IP address, because they are obviously too massive in number to easily achieve a sane addressing scheme. My point is that in the face of such massive waste, the smaller amounts of needless consumption become irrelevent. If you are justifying consuming 2*10**25 IP addresses on one-time-use nanonites, you can certainly spend 5% of your IPv6 address space on point-to-point links without the P-t-P links being the issue. 5% would be 100,000 P-t-P links in that case. Either way, one /43 would easily provide more than enough IPs for both nanonites and 100,000 /64 p-t-p links. And with a standard /40 subnet, you'd have 4 additional bits left over to work with, to sanely subnet your nanonites. The issue in scenarios like that one is the things there are a lot of that _consume_ many addresses. Point-to-point addresses are rare, much rarer than hosts, and much less massive in number than nanonites addressed onto a LAN would be, so giving a P-t-P link an an entire /64 should not be a consumption issue in any conceivable (likely) scenario, where a proper amount of IPv6 space has been obtained in the first place. -- -J
Re: Using /126 for IPv6 router links
On 1/23/2010 8:24 PM, Owen DeLong wrote: On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) Use the /64... It's OK... IPv6 was designed with that in mind. 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? -- 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
Sometimes good enough perfect Never know what is going to come along to turn your addressing plan on its head. -brandon On 1/23/10, Larry Sheldon larryshel...@cox.net wrote: On 1/23/2010 8:24 PM, Owen DeLong wrote: On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) Use the /64... It's OK... IPv6 was designed with that in mind. 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? -- 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 -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Re: Using /126 for IPv6 router links
On Sat, 23 Jan 2010 20:55:52 -0600 Brandon Galbraith brandon.galbra...@gmail.com wrote: Sometimes good enough perfect Never know what is going to come along to turn your addressing plan on its head. It seems to me that what this really is about is trying to be in the best position in the future. I think mainly it's about trying to avoid unexpected and future renumbering/change of prefix length costs. Possible positions or situations are : 1. you use a variety of node address lengths across your network, and there are no future consequences - everything works and continues to work 2. you use a single node address length (i.e. /64) across your network, and there are no future consequences - everything works and continues to work 3. you use a variety of node address lengths, and you'll have to renumber to /64s, because you encounter unacceptable issues e.g. device performance issues, inability to use features you'd find useful e.g. SEND. 4. you use a single node address length, and you'll have to move to variable length node addresses, because the IPv6 address space ends up not being as big as it was designed and calculated to be. Ideally, situations one 1. or 2. will occur, as they're the least costly. 1. is both initially and operationally slightly more costly than 2. as you'll also have to also accurately manage prefix lengths, and consider and/or address other non-/64 issues identified in RFC3627, which I think makes 2. the better choice. The question is, which of those two has the least risk of devolving into the corresponding 3. or 4? As the addressing architecture documents for IPv6 currently state that for other than addresses that start with binary 000, the interface ID are required to be 64 bits in length, it seems to me that situation 2. is the least risky and least likely to devolve into situation 4. Vendors/developers using RFCs as authoritative IPV6 documents are going to assume /64s, as are future protocol developers. -brandon On 1/23/10, Larry Sheldon larryshel...@cox.net wrote: On 1/23/2010 8:24 PM, Owen DeLong wrote: On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) Use the /64... It's OK... IPv6 was designed with that in mind. 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? -- 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 -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Re: Using /126 for IPv6 router links
That's why we have the safety valve... 2000::/3 is the total address space being issued currently. So, if we discover that there aren't enough /64s like we currently think there are, then, before we start issuing from 4000::/3, we can have a new address plan for that address space while leaving the 2000::/3 in it's current state of 1, or, ideally, 2. Owen On Jan 23, 2010, at 7:06 PM, Mark Smith wrote: On Sat, 23 Jan 2010 20:55:52 -0600 Brandon Galbraith brandon.galbra...@gmail.com wrote: Sometimes good enough perfect Never know what is going to come along to turn your addressing plan on its head. It seems to me that what this really is about is trying to be in the best position in the future. I think mainly it's about trying to avoid unexpected and future renumbering/change of prefix length costs. Possible positions or situations are : 1. you use a variety of node address lengths across your network, and there are no future consequences - everything works and continues to work 2. you use a single node address length (i.e. /64) across your network, and there are no future consequences - everything works and continues to work 3. you use a variety of node address lengths, and you'll have to renumber to /64s, because you encounter unacceptable issues e.g. device performance issues, inability to use features you'd find useful e.g. SEND. 4. you use a single node address length, and you'll have to move to variable length node addresses, because the IPv6 address space ends up not being as big as it was designed and calculated to be. Ideally, situations one 1. or 2. will occur, as they're the least costly. 1. is both initially and operationally slightly more costly than 2. as you'll also have to also accurately manage prefix lengths, and consider and/or address other non-/64 issues identified in RFC3627, which I think makes 2. the better choice. The question is, which of those two has the least risk of devolving into the corresponding 3. or 4? As the addressing architecture documents for IPv6 currently state that for other than addresses that start with binary 000, the interface ID are required to be 64 bits in length, it seems to me that situation 2. is the least risky and least likely to devolve into situation 4. Vendors/developers using RFCs as authoritative IPV6 documents are going to assume /64s, as are future protocol developers. -brandon On 1/23/10, Larry Sheldon larryshel...@cox.net wrote: On 1/23/2010 8:24 PM, Owen DeLong wrote: On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. 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 ? ;) Use the /64... It's OK... IPv6 was designed with that in mind. 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? -- 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 -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141
Re: Using /126 for IPv6 router links
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. -- 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
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. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpmW9UnydIXo.pgp Description: PGP signature
Re: Anyone see a game changer here?
On Thu, Jan 21, 2010 at 7:52 PM, Gadi Evron g...@linuxbox.org wrote: I just wrote a blog on the subject called the fog of cyberwar: http://darkreading.com/blog/archives/2010/01/fog_of_cyberwar.html In short: While we are all talking of Google's morals and US/China diplomacy, there are some questions that mostly remain unasked: 1. Did Google hack a Taiwanese server to investigate the breach? If so, good for them. Our ethics need to catch up to our morals, as we usually wake up to a new world others created for us, a few years too late. But, for now, it's still illegal so some details would be nice. From your blog post: While reporting is vague, Google has supposedly broken into a server in Taiwan (unless information of working through Taiwanese authorities, or that someone else has done this for Google, becomes available). 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. Damian -- Damian Menscher :: Security Reliability Engineer :: Google
Re: Anyone see a game changer here?
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? Gadi.
Re: Anyone see a game changer here?
On 1/24/10 7:20 AM, Gadi Evron 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. To illustrate, you quoted: While reporting is vague, Google has supposedly broken into a server in Taiwan (unless information of working through Taiwanese authorities, or that someone else has done this for Google, becomes available). The paragraph continues, with: If this happened, ... I hope this solves any misunderstanding. Gadi.
Re: Anyone see a game changer here?
On Sat, Jan 23, 2010 at 9:20 PM, Gadi Evron g...@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. Damian -- Damian Menscher :: Security Reliability Engineer :: Google
looking for Rogers Wireless DNS contact
hi there, looks like Rogers Wireless is the only mobile carrier in the world that does not want to resolve our server hostname correctly. anybody from Rogers Wireless here who can help or can point me in the right direction? thanks, -- jan
