Re: Token ring? topic hijack: was Re: Mystery open source switching
Jacob Broussard shadowedstran...@gmail.com wrote: Wow... Reading this thread I feel like some sort of time traveler, what with my cable internet, multicore processor, and smartphone. Just in case it isn't clear, I use all of my ancient computing and network technology by a *very* deliberate choice. Just take the case of the hardware gadget I've designed and built myself that goes from SDSL/ATM to V.35-nee-EIA-530: I've only built and deployed it in the summer of this year, although I had wanted one since late 2004 and had been developing it as a hobby open source hardware project since 2006. MS
Re: Token ring? topic hijack: was Re: Mystery open source switching
I wasn't trying to imply anything with my comment, it was meant as a cheap joke. I apologize if I gave that impression. I am still very young and have never heard of most of these, other than atm and x.25... Old hardware really interests me as I still have my first computer (laptop with slide out trackball, external scsi cd-rom, and 10base2 networking.) Anyway back to lurking for me. On Nov 3, 2010 1:21 AM, Michael Sokolov msoko...@ivan.harhan.org wrote:
Re: Token ring? topic hijack: was Re: Mystery open source switching
On 11/02/2010 10:47 PM, Jacob Broussard wrote: I guess I am not as funny as I thought I was. None of us are. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, 3 Nov 2010 04:14:51 + (UTC) Sven Olaf Kamphuis s...@cb3rob.net wrote: I've had a recent experience of this. Some IPv6 CPE I was testing had a fault where it dropped out and recovered every 2 minutes - a transient network fault. I was watching a youtube video over IPv6. Because of the amount of video buffering that took place, and because the same IPv6 prefixes were assigned to the connection once it recovered, the youtube video kept playing. That was a great end-user experience and it was somewhat addictive to watch the PPP light go off and come back on while the video kept playing faultlessly. thats primarily due to partial http downloads aka http status 206 rather than 202 where you can just specify at which offset in the file you want the httpd to start reading the file to you, most flash movie players, however, don't support this. connection lost = movie has to be fully reloaded. There's a whole lot of speculation and no evidence in that statement ... as it said, it was faultless, so I very strongly doubt there was any restarting the stream.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 2, 2010, at 3:26 PM, Karl Auer wrote: On Tue, 2010-11-02 at 09:03 -0700, Owen DeLong wrote: About the only hack I can see that *might* make sense would be that home CPE does NOT honour the upstream lifetimes if upstream connectivity is lost, but instead keeps the prefix alive on very short lifetimes until upstream connectivity returns. Which is exactly what was being proposed when Tim responded that it would break the IPv6 spec. Yes it does. But as long as there is no upstream connectivity, it doesn't matter. Personally I don't think it makes a *lot* of sense, but it does make some. Sounds like we're in violent agreement. Owen
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
massive snip Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do. However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main = reasons that Google does not publish records generally today). However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc. There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration. You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs Sure, or, you can use PI without ULA and not need to develop a tool. If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64. Preference the ULA/64 addresses first (link). Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next. Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs outside of 2002::/16] Preference fc00::/7 last. For ULA/64 destination select a source address from the corresponding ULA/64. For ULA/48 destination select a source address from the corresponding ULA/48. For PA/PI/6to4/64 destination addresses select a source address from the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last. Now is that really so hard? It just took you 20+ lines to describe the process in english without producing a single line of code. PI without ULA strikes me as being a lot less complicated. I'm not sure where the IETF is with revising the default address selection rules but ULA came out after the first set of rules was published so it needs to be taken into account if it hasn't already been. It doesn't matter where the IETF is. What matters is how many systems are deployed with what address selection rules and how long they would take to change if IETF ever did make up their mind on new standards. If you are merging two sites you just extend the ULA of one to cover the other as well then slowly deprecate the other or tweak the rules above and distribute them via DHCP. Or you use PI and don't worry about it at all. You're making a very good case fro why ULA is vastly inferior to PI. Owen
RE: Token ring? topic hijack: was Re: Mystery open source switching
Kinda makes me miss the old 6544 cluster controller that I turned into a kegerator/end table/lamp.. ;-) -Original Message- From: George Bonser [mailto:gbon...@seven.com] Sent: Wednesday, November 03, 2010 3:15 AM To: Jacob Broussard Cc: nanog@nanog.org Subject: RE: Token ring? topic hijack: was Re: Mystery open source switching Old hardware really interests me as I still have my first computer (laptop with slide out trackball, external scsi cd-rom, and 10base2 networking.) Anyway back to lurking for me. On Nov 3, 2010 1:21 AM, Michael Sokolov msoko...@ivan.harhan.org wrote: I think I still have an old COSMAC ELF out in the garage. However, it's networking capabilities are severely limited.
RE: Token ring? topic hijack: was Re: Mystery open source switching
To my knowledge Simplex Grinnell fire detection systems currently use token ring. The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] Sent: Tue 11/2/2010 3:44 PM To: nanog@nanog.org Subject: Re: Token ring? topic hijack: was Re: Mystery open source switching Not only token ring. I know of some coaxial ethernets that were running as late as 2007. Some ATM machines still use X.25. And I know of at least one operational CNLP network (not a commercial one though) cheers! Carlos On Mon, Nov 1, 2010 at 11:21 AM, Greg Whynott greg.whyn...@oicr.on.cawrote: off topic... you recently converted from token ring to ethernet? i had no idea there was still token ring networks out there, or am i living in a bubble? -g On Oct 31, 2010, at 9:07 PM, Paul WALL wrote: I don't know what the big deal is. I've rolled at least 20 of these switches into my network, and not only are they more stable than the Centillion switches that they replaced, they only cost half as much. Most of the money I dropped was on converting my stations from token ring to ethernet. On Sun, Oct 31, 2010 at 6:59 PM, bas kilo...@gmail.com wrote: Hi, On Sat, Oct 30, 2010 at 11:26 PM, Kevin Oberman ober...@es.net wrote: I might also mention that I received private SPAM from a name we all know and loath. (Hint: He's been banned from NANOG for VERY good reason and his name is of French derivation.) I just added a filter to block any mail mentioning pica8 and will see no more of this thread or their spam. Same here. He harvests email addresses from peeringdb. (I have slight typo's in my peeringdb record to recognize harvested spams.) Bas -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: Token ring? topic hijack: was Re: Mystery open source switching
On Nov 3, 2010, at 10:08 AM, Adcock, Matt [HISNA] madc...@hisna.com wrote: To my knowledge Simplex Grinnell fire detection systems currently use token ring. I can't believe I got through is thread (unless the iPhone threading is more broken than usual) without anyone mentioning the fibre channel over token ring alliance (http://fcotr.org)
Re: Token ring? topic hijack: was Re: Mystery open source switching
And you live in a cabin in the woods, pedal a generator to get the router up and the router is connected to a 56K Dial-up morem? ;-) Gary B Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Hats off!! You should post some pictures! As in ASCII art pictures? Because my life revolves around ASCII text and I abhor anything that isn't ASCII text, I do not own a camera of any kind, never have and likely never will. MS
Re: Token ring? topic hijack: was Re: Mystery open source switching
OK, I haven't taken it back out of the box, but anyone still have 8 bit ISA Arcnet with thin coax? I HATE soldering the terminating resistors... :-( Gary B On 11/02/2010 10:34 PM, Julien Goodwin wrote: On 03/11/10 13:11, Express Web Systems wrote: The network I am using to compose and post this message right now is a coaxial Ethernet. MS Thick or Thin? Bonus points for 10-Base-5. Super bonus points (and presumably therapy) for 10-broad-36.
Re: Token ring? topic hijack: was Re: Mystery open source switching
On Wed, Nov 3, 2010 at 8:15 AM, Gary Baribault g...@baribault.net wrote: OK, I haven't taken it back out of the box, but anyone still have 8 bit ISA Arcnet with thin coax? No, but I remember controlling stacks of Mulitech modems with an Arcnet RJ-11 connection on Windows 3.1. I think the Arcnet hub is still kicking around here under a pile in the garage. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
Re: Token ring? topic hijack: was Re: Mystery open source switching
Gary Baribault g...@baribault.net wrote: And you live in a cabin in the woods, pedal a generator to get the router up and the router is connected to a 56K Dial-up morem? I have never used those 56K dial-up modems because they are asymmetric: it's only 56K in the downstream direction, and I oppose that on principle. Prior to switching to my current 384 kbps SDSL (served by a V.35 CPE device of my own design and make, see earlier messages in this thread), I was using an always-on (immediate redial on disconnect) analog modem connection at 31200 bps. One of the 4.3BSD-Quasijarus MicroVAXen acted as the router, and the PPP implementation in the kernel was written by me from scratch: the original non-Quasijarus 4.3BSD only had SLIP. MS
Re: IPv6 rDNS
On Tue, 02 Nov 2010 18:21:14 -, Sven Olaf Kamphuis said: getting rid of bind has various other advantages, such as no longer needing tcp to transfer zone files (Retarded concept to say the least) so there are no more tcp issues related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance! Till the first time you have to answer a query that's over 512 bytes that doesn't have the EDNS0 bit set... Yes, such beasts still live out there. pgpH8IMAABZgZ.pgp Description: PGP signature
Re: Token ring? topic hijack: was Re: Mystery open source switching
On Tuesday, November 02, 2010 04:55:02 pm Michael Sokolov wrote: Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Not only token ring. I know of some coaxial ethernets that were running as late as 2007. The network I am using to compose and post this message right now is a coaxial Ethernet. Oh man I still have some 10Base-5 segments in production. At least I'm using a 7507 with an AUI Ethernet interface processor to drive them, now, instead of the three Proteon P4200's (software to P5600, with IP, EGP, RIP, OSPF, XNS, DNA, X.25, etc) that were used prior. The three P4200's hooked up to each other with ProNET-80 over fiber (using the P3280 counterrotating ring unit). Kindof cool to have floppies with the JNC copyright on themsoftware release R8.1, 02/06/91. Last time I checked, two of the P4200's still booted up. 2MB of RAM with a 68020 at 16MHz. Sounds like a Cisco AGS. The fiber portion is now 1000Base-SX and LX, but rather than rewire some areas, we just pop some older switches with AUI 'uplinks' and use the thicknet, which still runs well (as well as thicknet can) after all these years. Some of the areas the thicknet traverses would be a difficult rewire, thanks to 'right-sized' conduit and vampire taps. And if it ain't broke. ProNet-80.TokenRing on steroids. Worked better than the IBM 8220 TR-Fiber boxes, even using the old mini-BNC connectors.
Re: IPv6 rDNS
On Tuesday, November 02, 2010 02:21:14 pm Sven Olaf Kamphuis wrote: getting rid of bind has various other advantages, such as no longer needing tcp to transfer zone files (Retarded concept to say the least) so there are no more tcp issues related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance! Performing zone transfers is not the only reason for 53/tcp; it can also be needed for long (512 byte) query responses. Thanks to the one-two punch of DNSSEC and IPv6, the probability of a DNS reponse needing TCP on port 53 is much greater now.
Re: Token ring? topic hijack: was Re: Mystery open source switching
On Wed, 3 Nov 2010, Michael Sokolov wrote: Michael Painter tvhaw...@shaka.com wrote: Thick or Thin? Thin. I *so* wish I had thick coaxial Ethernet, but alas, my present physical facility is just too small for that: my present coax Ethernet network is contained within a single machine room which is a converted bedroom. I've found some thicknet + vampire taps in a few wiring closets of some of our older buildings, but it is all out of service. It wil lget ripped out when that building is gutted for a major overhaul in the next 1-2 years. jms
Re: Token ring? topic hijack: was Re: Mystery open source switching
Gary Baribault g...@baribault.net writes: OK, I haven't taken it back out of the box, but anyone still have 8 bit ISA Arcnet with thin coax? Sorry bro, only Farallon PhoneNet and Gatorboxes here. back to the shadows -r
RE: Token ring? topic hijack: was Re: Mystery open source switching
On Wed, 3 Nov 2010, Richard Graves (RHT) wrote: Kinda makes me miss the old 6544 cluster controller that I turned into a kegerator/end table/lamp.. ;-) I know of a DEC PDP-11 and a Wellfleet BCN that met a similar end :) jms -Original Message- From: George Bonser [mailto:gbon...@seven.com] Sent: Wednesday, November 03, 2010 3:15 AM To: Jacob Broussard Cc: nanog@nanog.org Subject: RE: Token ring? topic hijack: was Re: Mystery open source switching Old hardware really interests me as I still have my first computer (laptop with slide out trackball, external scsi cd-rom, and 10base2 networking.) Anyway back to lurking for me. On Nov 3, 2010 1:21 AM, Michael Sokolov msoko...@ivan.harhan.org wrote: I think I still have an old COSMAC ELF out in the garage. However, it's networking capabilities are severely limited.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
In message 2ce5a700-eb60-453f-85cf-5e679e94e...@delong.com, Owen DeLong write s: massive snip =20 Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do. =20 However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main =3D reasons that Google does not publish records generally today). =20 However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc. =20 There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration. =20 You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs =20 Sure, or, you can use PI without ULA and not need to develop a tool. Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. If you can get PI *and* get it routed then yes PI is the way to go. PA alone is also not the way to go. If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64. =20 Preference the ULA/64 addresses first (link).=20 Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a = good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next.=20 Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs = outside of 2002::/16] Preference fc00::/7 last. =20 For ULA/64 destination select a source address from the corresponding = ULA/64. For ULA/48 destination select a source address from the corresponding = ULA/48. For PA/PI/6to4/64 destination addresses select a source address from = the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from = the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 = address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. =20 Now is that really so hard? =20 It just took you 20+ lines to describe the process in english without = producing a single line of code. PI without ULA strikes me as being a lot less complicated. And PA alone doesn't work well. As for lines of code they won't be many as basically it is just inserting/removing rules when addresses are assigned/removed to/from interfaces. I'm not sure where the IETF is with revising the default address selection rules but ULA came out after the first set of rules was published so it needs to be taken into account if it hasn't already been. It doesn't matter where the IETF is. What matters is how many systems are deployed with what address selection rules and how long they would take to change if IETF ever did make up their mind on new standards. If you are merging two sites you just extend the ULA of one to cover the other as well then slowly deprecate the other or tweak the rules above and distribute them via DHCP. Or you use PI and don't worry about it at all. You're making a very good case fro why ULA is vastly inferior to PI. Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 rDNS
On 11/3/2010 at 1:10 PM, Lamar Owen lo...@pari.edu wrote: On Tuesday, November 02, 2010 02:21:14 pm Sven Olaf Kamphuis wrote: getting rid of bind has various other advantages, such as no longer needing tcp to transfer zone files (Retarded concept to say the least) so there are no more tcp issues related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance! Performing zone transfers is not the only reason for 53/tcp; it can also be needed for long (512 byte) query responses. Thanks to the one-two punch of DNSSEC and IPv6, the probability of a DNS reponse needing TCP on port 53 is much greater now. That's mitigated by the fact EDNS0 is required for DNSSEC allowing for larger queries to go over UDP. Still, blocking 53/tcp is perhaps second only to dropping all incoming ICMP in the quest to be the most widely deployed and severely broken thing done in the name of Internet security. -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, Nov 3, 2010 at 6:43 PM, Mark Andrews ma...@isc.org wrote: Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. not everyone's network requires 'routed' ... wrt the internet.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote: In message 2ce5a700-eb60-453f-85cf-5e679e94e...@delong.com, Owen DeLong write s: massive snip =20 Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do. =20 However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main =3D reasons that Google does not publish records generally today). =20 However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc. =20 There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration. =20 You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs =20 Sure, or, you can use PI without ULA and not need to develop a tool. Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. It's very easy to get PIv6 routed for free, so, I don't see the issue there. If you can get PI *and* get it routed then yes PI is the way to go. PA alone is also not the way to go. OK, so, PI is the way to go, since you can get it routed for free. (If you don't know how, see http://tunnelbroker.net and look for the subject BGP tunnel) If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64. =20 Preference the ULA/64 addresses first (link).=20 Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a = good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next.=20 Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs = outside of 2002::/16] Preference fc00::/7 last. =20 For ULA/64 destination select a source address from the corresponding = ULA/64. For ULA/48 destination select a source address from the corresponding = ULA/48. For PA/PI/6to4/64 destination addresses select a source address from = the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from = the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 = address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. =20 Now is that really so hard? =20 It just took you 20+ lines to describe the process in english without = producing a single line of code. PI without ULA strikes me as being a lot less complicated. And PA alone doesn't work well. Where did PA enter into my statement above? As for lines of code they won't be many as basically it is just inserting/removing rules when addresses are assigned/removed to/from interfaces. And then distributing those rules to EVERY host (or you have to pre- distribute the script to EVERY host). snip Owen
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, 03 Nov 2010 17:01:32 PDT, Owen DeLong said: On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote: Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. It's very easy to get PIv6 routed for free, so, I don't see the issue there. It may be very easy to get it routed for free *now*. Will it be possible to get PIv6 routed for free once there's 300K entries in the IPv6 routing table? Or zillions, as everybody and their pet llama start using PI prefixes? (Hey, if you managed to get PI to use instead of using an ULA, and routing it is free, may as well go for it, right?) pgpO3n6zJfVdQ.pgp Description: PGP signature
Verizon off-list contact requested
Hello- Would someone with clue within the Verizon team contact me off-list, please? I'm not seeing rDNS entries for new fios ip addresses. Regards, Ed Trdina
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 3, 2010, at 5:21 PM, valdis.kletni...@vt.edu wrote: On Wed, 03 Nov 2010 17:01:32 PDT, Owen DeLong said: On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote: Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. It's very easy to get PIv6 routed for free, so, I don't see the issue there. It may be very easy to get it routed for free *now*. Will it be possible to get PIv6 routed for free once there's 300K entries in the IPv6 routing table? Or zillions, as everybody and their pet llama start using PI prefixes? (Hey, if you managed to get PI to use instead of using an ULA, and routing it is free, may as well go for it, right?) Hopefully by the time it gets to that point we'll have finally come up with a scaleable routing paradigm. Certainly we need to do that anyway. I'm not sure why we chose not to do that with IPv6 in the first place. Owen
