Clarification from Pica8 (was Fwd: Mystery open source switching company claims top-of-rack price edge)
I just talked to Lin Du (who I worked with when I was at Woven), who is the current CEO of Pica8. Don't know anything about the product, but this didn't seem like Lin's style. Turns out Fontaine GUILLAUME has registered pic8@gmail.com, has no relation to the company - and is trying to prove to them that he should be a reseller. Lin has told GUILLAUME to stop (not that that will do any good). Some e-mail fragments below. Chris Begin forwarded message: From: Lin Du l...@pica8.com Date: 01 November 2010 17.11.58 +1100 To: Christopher LILJENSTOLPE c...@asgaard.org Subject: Re: Mystery open source switching company claims top-of-rack price edge Hi, Chris, Thanks for your reminding. This guy wants to resell the Pronto products but without any partnership with us yet. He even registered an email with my name as pica8@gmail.com for posting. I sent another email to let him stop doing this anymore. I need to clarify NANOG for this. Thanks, Lin From: Christopher LILJENSTOLPE Sent: Monday, November 01, 2010 12:31 PM To: Lin Du Subject: Re: Mystery open source switching company claims top-of-rack price edge NP. Chris On 01Nov2010, at 15.30, Lin Du wrote: Chris, Many thanks. Guillaume, Please stop using pica8 name in your posts, emails and any other public messages. We didn't grant you to do in this way. You could be pica8 partner until you are legally qualified. Thanks, Lin Pica8 Technology Inc. snip
Re: Clarification from Pica8 (was Fwd: Mystery open source switching company claims top-of-rack price edge)
Oh good lord, when will that guy ever stop. On 01-Nov-2010, at 2:52 PM, Christopher LILJENSTOLPE wrote: I just talked to Lin Du (who I worked with when I was at Woven), who is the current CEO of Pica8. Don't know anything about the product, but this didn't seem like Lin's style. Turns out Fontaine GUILLAUME has registered pic8@gmail.com, has no relation to the company - and is trying to prove to them that he should be a reseller. Lin has told GUILLAUME to stop (not that that will do any good). Some e-mail fragments below. Chris Begin forwarded message: From: Lin Du l...@pica8.com Date: 01 November 2010 17.11.58 +1100 To: Christopher LILJENSTOLPE c...@asgaard.org Subject: Re: Mystery open source switching company claims top-of-rack price edge Hi, Chris, Thanks for your reminding. This guy wants to resell the Pronto products but without any partnership with us yet. He even registered an email with my name as pica8@gmail.com for posting. I sent another email to let him stop doing this anymore. I need to clarify NANOG for this. Thanks, Lin From: Christopher LILJENSTOLPE Sent: Monday, November 01, 2010 12:31 PM To: Lin Du Subject: Re: Mystery open source switching company claims top-of-rack price edge NP. Chris On 01Nov2010, at 15.30, Lin Du wrote: Chris, Many thanks. Guillaume, Please stop using pica8 name in your posts, emails and any other public messages. We didn't grant you to do in this way. You could be pica8 partner until you are legally qualified. Thanks, Lin Pica8 Technology Inc. snip Kind regards, Mark
Re: Clarification from Pica8 (was Fwd: Mystery open source switchingcompany claims top-of-rack price edge)
Hahah. I love it when my hunch is correct. I swear that he ate lead paint chips as a kid. The b will be visiting soon I bet Tammy A Wisdom Summit Open Source Development Group -Original Message- From: Christopher LILJENSTOLPE c...@asgaard.org Date: Mon, 1 Nov 2010 17:52:23 To: nanog@nanog.org Subject: Clarification from Pica8 (was Fwd: Mystery open source switching company claims top-of-rack price edge) I just talked to Lin Du (who I worked with when I was at Woven), who is the current CEO of Pica8. Don't know anything about the product, but this didn't seem like Lin's style. Turns out Fontaine GUILLAUME has registered pic8@gmail.com, has no relation to the company - and is trying to prove to them that he should be a reseller. Lin has told GUILLAUME to stop (not that that will do any good). Some e-mail fragments below. Chris Begin forwarded message: From: Lin Du l...@pica8.com Date: 01 November 2010 17.11.58 +1100 To: Christopher LILJENSTOLPE c...@asgaard.org Subject: Re: Mystery open source switching company claims top-of-rack price edge Hi, Chris, Thanks for your reminding. This guy wants to resell the Pronto products but without any partnership with us yet. He even registered an email with my name as pica8@gmail.com for posting. I sent another email to let him stop doing this anymore. I need to clarify NANOG for this. Thanks, Lin From: Christopher LILJENSTOLPE Sent: Monday, November 01, 2010 12:31 PM To: Lin Du Subject: Re: Mystery open source switching company claims top-of-rack price edge NP. Chris On 01Nov2010, at 15.30, Lin Du wrote: Chris, Many thanks. Guillaume, Please stop using pica8 name in your posts, emails and any other public messages. We didn't grant you to do in this way. You could be pica8 partner until you are legally qualified. Thanks, Lin Pica8 Technology Inc. snip
Re: BGP support on ASA5585-X
Juniper srx runs JunOS. On Sat, Oct 30, 2010 at 11:31 AM, Jeffrey Lyon jeffrey.l...@blacklotus.net wrote: Juniper Netscreen does, in case the OP is looking for alternatives. Best regards, Jeff -- Suresh Ramasubramanian (ops.li...@gmail.com)
RE: IPv6 rDNS
Since there's a thread here, I'll mention rDNS for residential users. I'm not sure there's consensus about whether forward and reverse ought to match (how strong a should is that?). I know you can't populate every potential record in a reverse zone, as in IPv4. You can generate records on the fly, or just not provide PTRs. I've described options in draft-howard-isp-ip6rdns-04 but I'm not sure enough people care whether it's published as an RFC. Discuss on IETF's dnsop list. https://www.ietf.org/mailman/listinfo/dnsop Lee -Original Message- From: Jeroen van Aart [mailto:jer...@mompl.net] Sent: Friday, October 29, 2010 9:07 PM To: NANOG list Subject: IPv6 rDNS I battled for a few hours getting IPv6 rDNS to work. The following tool proved to be quite helpful: http://www.fpsn.net/?pg=toolstool=ipv6-inaddr Just in case anyone else would run into similar problems. It's not as straightforward as IPv4 rDNS. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
Define long prefix length. Owen has been fairly forceful in his advocacy of /48s at every site. Is this too long a prefix? Should peers only except /32s and shorter? On Sun, Oct 31, 2010 at 1:12 PM, David Conrad d...@virtualized.org wrote: On Oct 31, 2010, at 9:01 AM, Owen DeLong wrote: Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space? I really don't expect this to be as much of an issue in IPv6. Why would the commercial interests that have driven ISPs to remove long prefix length filters in IPv4 not apply to IPv6? Regards, -drc
Token ring? topic hijack: was Re: Mystery open source switching
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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On 01 Nov 2010 10:08, Jason Iannone wrote: Define long prefix length. Owen has been fairly forceful in his advocacy of /48s at every site. Is this too long a prefix? Should peers only except /32s and shorter? One assumes unpaid peers will accept prefixes up to the maximum length the RIR issues for that block, which is currently either /32 (PA) or /48 (PI). Presumably, long means any prefix longer than that; paid peers may accept those as well, but one assumes unpaid peers will not. 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
APRICOT 2011 Call For Papers
Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 15 - 25 February 2011, Hong Kong http://www.apricot2011.net CALL FOR PAPERS === The APRICOT 2011 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2011. We are looking for people and proposals that would: - Offer a technical tutorial on an appropriate topic; and/or - Participate in the technical conference sessions as a speaker; and/or - Convene and chair a Birds of a Feather (BOF) session. Please submit proposals on-line at http://www.apricot2011.net/call-for-papers/submission CONFERENCE MILESTONES - Call for Papers Opens: 29 October 2010 First Deadline for Submissions:29 November 2010 First Draft Programme Published:6 December 2010 Final Deadline for Submissions: 4 February 2011 Final Programme Published: 11 February 2011 Final Slides Received: 19 February 2011 PROGRAM MATERIAL The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content Service Delivery (Multicast, Voice, Video, telepresence, Gaming) CFP SUBMISSION -- Draft slides for both tutorials and conference sessions MUST be provided with CFP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at http://www.apricot2011.net/call-for-papers/submission Any questions or concerns should be addressed to the Programme Committee by e-mail. We look forward to receiving your presentation proposals. Jonny Martin Mark Tinka Co-Chairs, APRICOT Programme Committee prog...@apricot.net
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 10:24:31 + (GMT) Tim Franklin t...@pelican.org wrote: Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? I've seen this last point come up a few times, and I really don't get it. If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so your devices are using a prefix that has connectivity. If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned prefix all the time, regardless of the state of your WAN connection? This isn't to do with anything low level like RAs. This is about people proposing every IPv6 end-site gets PI i.e. a default free zone with multiple billions of routes instead of using ULAs for internal, stable addressing. It's as though they're not aware that the majority of end-sites on the Internet are residential ones, and that PI can scale to that number of end-sites. I can't see any other way to interpret we ought to make getting PI easy, easy enough that the other options just don't make sense. Regards, Mark.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@virtualized.org wrote: On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote: If Woody had gone straight to a ULA prefix, this would never have happened... Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent. Seems to me the options are: 1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell. My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers. That would seem to leave (3). Am I missing an option? I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense. Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? all the world is not a corner case... I don't think sane folks are supportive of 'every end site gets pi', I think it's somewhat sane to believe that enterprise type folks can/should be able to get PI space to suit their needs. ULA for enterprises is really not a good solution. Cable/dsl end users can certainly apply for PI space they may even be able to justify an allocation (see owen...) I don't think they'll have much success actually getting a DSL/Cable provider to actually hold the route for them though... so I'm not sure that your pathological case matters here. -chris
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 1, 2010, at 2:28 AM, Mark Smith wrote: On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@virtualized.org wrote: On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote: If Woody had gone straight to a ULA prefix, this would never have happened... Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent. Seems to me the options are: 1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell. My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers. That would seem to leave (3). Am I missing an option? I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense. Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? He may or may not be. I don't think it's such a bad idea. Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks. The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart. In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6. No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it. For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability. This is also false if you use any form of sanity in applying the assigned PA prefix to your network. In this common case of PA, how are you going to justify that no IPv6 without an IPv6 ISP view to people who are very remote, such that even intermittent Internet access is very occasional; to people who run IPv6 sensor networks and don't ever want them connected to the Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't affordable? These and similar are cases where only ISP PA or PI aren't acceptable. Nobody is trying to. This is a fallacy of logic that you keep pushing, but, it's still false. If I wire a PA prefix into my router, it doesn't go away just because the ISP does. All that happens is that I can't reach the internet from it, which is kind of true regardless of the address space used at the point where your ISP goes away. Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional. Why shouldn't PI if it was easy to get? I still don't understand the perceived advantage of ULA vs. PI other than the perception that it is easier to get. If PI is just as easy to get, why is it a problem? 2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?' There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit - http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order? Owen
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
This isn't to do with anything low level like RAs. This is about people proposing every IPv6 end-site gets PI i.e. a default free zone with multiple billions of routes instead of using ULAs for internal, stable addressing. It's as though they're not aware that the majority of end-sites on the Internet are residential ones, and that PI can scale to that number of end-sites. I can't see any other way to interpret we ought to make getting PI easy, easy enough that the other options just don't make sense. OK, sorry, I think we're addressing different points of the same comment. I was looking very much at the second half of all residential users get PI so that if their ISP disappears their network doesn't break, ie the reason *why* they'd want PI. I assumed that was disappears as in has an outage, rather than goes bust, user changes ISP etc - and if you've only got one ISP, you don't need PI or ULA to have *local* connectivity work through an ISP outage. I agree, on the current routing platforms we have, PI for every end site is insanity. Whether we should be looking for routing platforms (or a different architecture - LISP?) that allows PI for every end user is a different question... Regards, Tim.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
oops, I clipped a little too much from the message before replying... On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional. I think there are many cases where a 'disconnected' network will want ipv6, I do NOT believe they should use ULA space except in the most extreme cases. It makes more sense to just get these folks a GUA allocation of their proper size, support their DNS and registry needs. I agree that global connectivity should be optional... I've worked on more than one network that had better never see the light of day, and will most likely need (or already has?) ipv6 deployments in the coming months/years. -chris
Re: Token ring? topic hijack: was Re: Mystery open source switching
On 01/11/2010 15:21, Greg Whynott wrote: 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? Sadly, you're living in a bubble. As long as there are banks and very large commercial institutions, there will be legacy installations. Including t/r. And OS/2. And windows NT 3.51. And FDDI and X.25 and every single legacy protocol, type of hardware and ancient operating system that ever existed. Why do you think the Cisco 7500 only went EoS 3 years ago? Nick
RE: Token ring? topic hijack: was Re: Mystery open source switching
Halloween is over, why do you have to keep saying scary things like that.. (even if it is true, unfortunately) -Richard -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Monday, November 01, 2010 12:48 PM To: nanog@nanog.org Subject: Re: Token ring? topic hijack: was Re: Mystery open source switching On 01/11/2010 15:21, Greg Whynott wrote: 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? Sadly, you're living in a bubble. As long as there are banks and very large commercial institutions, there will be legacy installations. Including t/r. And OS/2. And windows NT 3.51. And FDDI and X.25 and every single legacy protocol, type of hardware and ancient operating system that ever existed. Why do you think the Cisco 7500 only went EoS 3 years ago? Nick
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 09:20:41 -0700 Owen DeLong o...@delong.com wrote: On Nov 1, 2010, at 2:28 AM, Mark Smith wrote: On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@virtualized.org wrote: On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote: If Woody had gone straight to a ULA prefix, this would never have happened... Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent. Seems to me the options are: 1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell. My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers. That would seem to leave (3). Am I missing an option? I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense. Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? He may or may not be. I don't think it's such a bad idea. How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation? Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks. The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart. Residential end-users aren't smart and aren't network engineers - they pay people like us so that they don't have to be. In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6. No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it. What if you don't have an IPv6 ISP connection? Where do you get your PA from? Link local isn't good enough, because it can't span more than a single link. Homes in the future are likely to have multiple networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc. You've stated you use link locals for this sort of thing, yet you'd be specifying the interface to use as well. That isn't much different to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link local address is specified, which also means performing an address type check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care. For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability. This is also false if you use any form of sanity in applying the assigned PA prefix to your network. I suppose since they don't have the expertise, you could consider residential end-users insane. You can't make the insane sane just by telling them to be so. Preventing their insanity from breaking their Internet
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
Hi, 2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?' There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit - http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 I'm a co-author of this draft. The draft was redirected to 6man wg at IETF, and has a filename: draft-fujisaki-6man-addr-select-opt-00 Unfortunately, I cannot declare it's gonna be ready soon. This proposal has been hanging in the air for long time without any remarkable progress. IMO, this is mainly due to lack of interests on this kind of issues, and lack of operator's perspective on it. I'm glad if anyone could make comments to the 6man list. Best regards, Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order? All the ones I use - they all seem to use the first getaddrinfo() response. They should be attempting to successively connect() to all responses in the order that getaddrinfo() returns as connect() failures occur. I don't know if they are (as destination reachability is usually good), however if they aren't, then the application developers haven't used getaddrinfo() correctly. That behaviour wouldn't be exclusive to IPv6 though - IPv4 applications should also be attempting to connect() to successive addresses when multiple are returned. IOW, applications coping with multiple responses to getaddrinfo() is not an exclusive issue to IPv6. I actually override the current default IPv6 address rules. Here's my /etc/gai.conf, which makes ULAs override GUAs as that currently isn't in the default address selection rules, and makes tunnelled IPv6 preferred over native IPv4, as I don't currently have native IPv6. The MRS entries are the non-defaults, the rest are from the gai.conf manual page. -- # Used for selecting source addresses # # label prefix label # label ::1/128 0 label ::/0 1 label 2002::/16 2 label 2000::/3 2 # MRS label ::/96 3 label :::0:0/96 4 label fc00::/7 5 # ULA - MRS # Used for sorting destination addresses # # precedence prefix precedence # precendence ::1/128 50 precendence ::/0 40 precendence fc00::/7 35 # ULA - MRS precendence 2000::/3 30 # MRS precendence 2002::/16 30 precendence ::/96 20 precendence :::0:0/96 10 --
RE: Ethernet performance tests
EXFO also sells the BRIX SLA verifier, which calculates RTT, packet loss, and jitter for various applications running on top of the link layer. -Original Message- From: Tim Jackson [mailto:jackson@gmail.com] Sent: Wednesday, October 27, 2010 6:54 PM To: Diogo Montagner Cc: nanog@nanog.org Subject: Re: Ethernet performance tests We dispatch a technician to an end-site and perform tests either head-head with another test set, or to a loop at a far-end.. We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the customer requirements. (some customers require certain tests for x minutes) http://www.exfo.com/en/Products/Products.aspx?Id=370 ^--All of our technicians are equipped with those EXFO sets and that module. Also covers SONET/DS1/DS3 testing as well in a single easy(er) to carry set.. -- Tim On Wed, Oct 27, 2010 at 6:32 PM, Diogo Montagner diogo.montag...@gmail.com wrote: Hello everyone, I am looking for performance test methodology for ethernet-based circuits. These ethernet circuits can be: dark-fiber, l2circuit (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet circuit can be a mix of these technologies, like below: CPE - metro-e - l2circuit - l2vpn - l2circuit - metro-e - CPE The goal is verify the performance end-to-end. I am looking for tools that can check at least the following parameters: - loss - latency - jitter - bandwidth - out-of-order delivery At this moment I have been used IPerf to achieve these results. But I would like to check if there is some test devices that can be used in situations like that to verify the ethernet-based circuit performance. The objective of these tests is to verify the signed SLAs of each circuit before the customer start to use it. I checked all MEF specifications and I only find something related to performance for Circuit Emulation over Metro-E (which is not my case). Appreciate your comments. Thanks! ./diogo -montagner
Re: IPv6 rDNS
Gary E. Miller wrote: See also sipcalc. Thanks, I wasn't aware of the various commandline tools available yet. Except the dig option to convert IPv6 rDNS. But the tool I mentioned also creates a whole zone file for you based on what you entered, which I then used to correct the zone file I created. I found that it helped me a lot more than lots and lots of wiki and gewgle searched pages which only explained bits and pieces and failed to give proper, or even incorrect and/or dated examples. So once I found that tool it took me a few minutes to get the syntax right. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: IPv6 fc00::/7 — Unique local addresses
Karl Auer wrote: On Thu, 2010-10-21 at 18:48 -0700, Owen DeLong wrote: Uh, no... You're misreading it. Yes - I read the ISP bit, not the end user bit. It cost me $625 (or possibly less) one-time when I first got it. That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that prohibitive but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price. That seems to be quite an argument against trying to get IPv6 GUA, or am I missing something? In my experience companies are often too cheap to even buy things like a software license, if the free product suffices. Often ignoring the hidden costs of dealing with a restricted free copy. So I'd say, that in my case, providing an internal IPv6 network for testing purposes, does not warrant getting GUAs. Even if it technically speaking is a good thing, it's not likely to happen. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: IPv6 fc00::/7 — Unique local addresses
It cost me $625 (or possibly less) one-time when I first got it. one time? truely one time? no other fees or strings? randy
Re: IPv6 fc00::/7 — Unique local addresses
On Mon, 2010-11-01 at 15:26 -0700, Jeroen van Aart wrote: Karl Auer wrote: That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that prohibitive but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price. That seems to be quite an argument against trying to get IPv6 GUA, or am I missing something? No you're not missing anything. And this is a good, simple policy tool to keep the numbers of PI routes down. At least from the US. But similar fees seem to be in force at other RIRs like APNIC and RIPE. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 rDNS
In message aanlktinumzyp9qe0i5phyz72al3xyctvaqhjzhutk...@mail.gmail.com, Mich el de Nostredame writes: On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart jer...@mompl.net wrote: I battled for a few hours getting IPv6 rDNS to work. The following tool proved to be quite helpful: http://www.fpsn.net/?pg=toolstool=ipv6-inaddr Just in case anyone else would run into similar problems. It's not as straightforward as IPv4 rDNS. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html Forgive me if this is a stupid question. I am curious that if BIND ever tried to make the DB file easier to operate under pure text-based environment. For example, allow something like following format inside zone file, $ORIGIN 1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. 48ff:fe35:d1bc PTR server.example.com. Firstly you don't have enough bits for a IPv6 address specified and secondly how would you distingish that from wanting the following? 48ff:fe35:d1bc.1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. PTR server.example.com. If you feel like writing a $6REVERSE directive please go ahead. We would be happy to accept such a patch. I would however make it take full IPv6 addresses and also take prefix syntax ((prefixlen % 4) == 0, as only nibble boundaries make sense) and allow $ORIGIN to be specified. e.g. $6REVERSE fd78:8413:830:1::/64 SOA $6REVERSE fd78:8413:830:1::/64 NS $6REVERSE fd78:8413:830:1::/64 NS $6REVERSE fd78:8413:830:1::48ff:fe35:d1bc PTR server.example.com. $6REVERSE $ORIGIN fd78:8413:830:1::/64 @ SOA ... @ NS ... @ NS ... one could make it more general and do both IPv4 and IPv6 ($REVERSE). And when load the zone file, automatically (internally) interpret it as c.b.1.d.5.3.e.f.f.f.8.4.1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. inside memory. Regards, -- Michel~ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Equinix of Candia?
Who if anyone is the Equinix of Candia? Cheers Ryan
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 1, 2010, at 9:07 AM, Mark Smith wrote: On Mon, 1 Nov 2010 10:24:31 + (GMT) Tim Franklin t...@pelican.org wrote: Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? I've seen this last point come up a few times, and I really don't get it. If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so your devices are using a prefix that has connectivity. If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned prefix all the time, regardless of the state of your WAN connection? This isn't to do with anything low level like RAs. This is about people proposing every IPv6 end-site gets PI i.e. a default free zone with multiple billions of routes instead of using ULAs for internal, stable addressing. It's as though they're not aware that the majority of end-sites on the Internet are residential ones, and that PI can scale to that number of end-sites. I can't see any other way to interpret we ought to make getting PI easy, easy enough that the other options just don't make sense. Making it easy enough to get PI that anyone who wants it can get it will not result in most residential customers choosing to go with PI. Most residential customers will continue with PA. This discussion was originally about businesses needing failover between providers which is an environment where I will continue to advocate PI over other solutions. For a single-homed residence that doesn't care, PA will remain easier on multiple levels than PI even if the RIRs were not involved at all. As to the ability to scale PI, that is a deficiency in the current routing paradigm which must be fixed eventually anyway. It's unfortunate that we chose not to address this in IPv6, but, so it is and we are where we are. Hopefully we can find a way to address it without needing another major rev. of the protocol that is application affecting since that's the actual hard part of the IPv6 migration. Owen Regards, Mark.
Re: Equinix of Candia?
Equinix at 151 Front? Drive Slow, Paul Wall On 11/1/10, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Who if anyone is the Equinix of Candia? Cheers Ryan -- Sent from my mobile device
Re: Equinix of Candia?
If you mean Canada, Equinix bought out Switch Data so Equinix is directly Sent from my iPhone On Nov 1, 2010, at 8:04 PM, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Who if anyone is the Equinix of Candia? Cheers Ryan
RE: Equinix of Candia?
Yes sorry it has been a long day. Canada. Is the only Switch Data center in Toronto? -Original Message- From: Kevin Karch [mailto:kevinka...@vackinc.com] Sent: Monday, November 01, 2010 9:16 PM To: 'David DiGiacomo' Cc: Ryan Finnesey Subject: RE: Equinix of Candia? We do have several carriers at that location. Please send your space, upstream and connectivity requirements and we will prepare a quote for you. Thank you, Kevin L. Karch Network Specialist Direct: 847-833-8810 Fax: 847-985-5550 Email: kevinka...@vackinc.com Web: www.vackinc.com The Optical Network Specialists -Original Message- From: David DiGiacomo [mailto:dav...@corp.nac.net] Sent: Monday, November 01, 2010 8:02 PM To: David DiGiacomo Cc: Ryan Finnesey; NANOG list Subject: Re: Equinix of Candia? ...somehow my email got cutoff Equinix is in 151 Front Street in Torono Sent from my iPhone On Nov 1, 2010, at 8:59 PM, David DiGiacomo dav...@corp.nac.net wrote: If you mean Canada, Equinix bought out Switch Data so Equinix is directly Sent from my iPhone On Nov 1, 2010, at 8:04 PM, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Who if anyone is the Equinix of Candia? Cheers Ryan
RE: Equinix of Candia?
Equinix only has one center within Toronto.Is there someone with a larger number of centers across the country? -Original Message- From: Paul WALL [mailto:pauldotw...@gmail.com] Sent: Monday, November 01, 2010 8:56 PM To: Ryan Finnesey; NANOG list Subject: Re: Equinix of Candia? Equinix at 151 Front? Drive Slow, Paul Wall On 11/1/10, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Who if anyone is the Equinix of Candia? Cheers Ryan -- Sent from my mobile device
RE: Equinix of Candia?
We have national coverage on several cities with common companies with the same company. Please let me know your locations of interest. Kevin L. Karch Network Specialist Direct: 847-833-8810 Fax: 847-985-5550 Email: kevinka...@vackinc.com Web: www.vackinc.com The Optical Network Specialists -Original Message- From: Ryan Finnesey [mailto:ryan.finne...@harrierinvestments.com] Sent: Monday, November 01, 2010 8:32 PM To: Paul WALL; NANOG list Subject: RE: Equinix of Candia? Equinix only has one center within Toronto.Is there someone with a larger number of centers across the country? -Original Message- From: Paul WALL [mailto:pauldotw...@gmail.com] Sent: Monday, November 01, 2010 8:56 PM To: Ryan Finnesey; NANOG list Subject: Re: Equinix of Candia? Equinix at 151 Front? Drive Slow, Paul Wall On 11/1/10, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Who if anyone is the Equinix of Candia? Cheers Ryan -- Sent from my mobile device
Re: Equinix of Candia?
On Mon, Nov 01, 2010 at 06:31:34PM -0700, Ryan Finnesey wrote: Equinix only has one center within Toronto. Is there someone with a larger number of centers across the country? I'm assuming when you say like Equinix you mean a carrier neutral colo where you can buy from, sell to, and interconnect with other networks in an interesting fashion. If you're just looking for a place to stuff some servers, the answer will be very different. Canada is an odd market, with relatively little competition between carriers (outside of a few locations), and most of the bandwidth controlled by a few large incumbents. The biggest and most interesting facility for carrier neutral services is 151 Front in Toronto, where nearly every bit in the region goes. Switch and Data (now Equinix) is one major colo and IX operator in the building, but there are many more, and a building MMR. Technically this makes it more like a 111 8th than an Equinix. :) In Montreal there is Canix (www.canix.ca), which operates multiple facilities throughout the city, and is the defacto standard for carrier neutral colo there. This is probably the closest thing you'll find to an Equinix. If there is anything interesting going on in Vancouver I haven't heard of it, but I don't know the market well enough to say for certain. Everywhere else is either too small to care about on a national scale, or is serviced by non-neutral colos (e.g. Peer1, etc). -- 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: Equinix of Candia?
Thank you Richard your reply was very helpful. Cheers Ryan -Original Message- From: Richard A Steenbergen [mailto:r...@e-gerbil.net] Sent: Monday, November 01, 2010 10:37 PM To: Ryan Finnesey Cc: NANOG list Subject: Re: Equinix of Candia? On Mon, Nov 01, 2010 at 06:31:34PM -0700, Ryan Finnesey wrote: Equinix only has one center within Toronto. Is there someone with a larger number of centers across the country? I'm assuming when you say like Equinix you mean a carrier neutral colo where you can buy from, sell to, and interconnect with other networks in an interesting fashion. If you're just looking for a place to stuff some servers, the answer will be very different. Canada is an odd market, with relatively little competition between carriers (outside of a few locations), and most of the bandwidth controlled by a few large incumbents. The biggest and most interesting facility for carrier neutral services is 151 Front in Toronto, where nearly every bit in the region goes. Switch and Data (now Equinix) is one major colo and IX operator in the building, but there are many more, and a building MMR. Technically this makes it more like a 111 8th than an Equinix. :) In Montreal there is Canix (www.canix.ca), which operates multiple facilities throughout the city, and is the defacto standard for carrier neutral colo there. This is probably the closest thing you'll find to an Equinix. If there is anything interesting going on in Vancouver I haven't heard of it, but I don't know the market well enough to say for certain. Everywhere else is either too small to care about on a national scale, or is serviced by non-neutral colos (e.g. Peer1, etc). -- 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: IPv6 fc00::/7 — Unique local addresses
On Nov 1, 2010, at 4:19 PM, Karl Auer wrote: On Mon, 2010-11-01 at 15:26 -0700, Jeroen van Aart wrote: Karl Auer wrote: That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that prohibitive but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price. That seems to be quite an argument against trying to get IPv6 GUA, or am I missing something? Interesting... I guess controlling your own internet fate hasn't been a priority for the companies where you've worked. Not one of my clients or the companies I have worked for has even given a second thought to approving the cost of address space once I presented the tradeoffs of PA vs. PI. Depending on your meaning of non-corporate (e.g. non-business or just not large business since this is unclear from your meaning and corporations come in all sizes including a single person), this may or may not be true. No you're not missing anything. And this is a good, simple policy tool to keep the numbers of PI routes down. At least from the US. But similar fees seem to be in force at other RIRs like APNIC and RIPE. The fees are not there to keep routes down. The fees are there to help the RIR recover the cost of maintaining the RIR and processing the application. Frankly, if we simplified the approval process we could probably lower the cost of reviewing these applications and thus lower the fees. Owen
Re: IPv6 fc00::/7 — Unique local addresses
On Nov 1, 2010, at 4:12 PM, Randy Bush wrote: It cost me $625 (or possibly less) one-time when I first got it. one time? truely one time? no other fees or strings? randy Yes, one time. Truly one time. No other fees. The $100/year I was already paying for my other resources covers it, so, no increase in annual fees. If you're starting from scratch, then there is a $100/year fee. As to strings, well, it's subject to policy like any other RIR issued addresses. I don't see that as a problem or really as a string, but, some might. Owen
Re: IPv6 fc00::/7 — Unique local addresses
Owen, On Nov 1, 2010, at 4:59 PM, Owen DeLong wrote: Yes, one time. Truly one time. No other fees. Let's say you returned all your IPv4 address space. What would happen if you then stopped paying? Regards, -drc
Re: IPv6 rDNS
On Nov 1, 2010, at 4:40 PM, Mark Andrews wrote: In message aanlktinumzyp9qe0i5phyz72al3xyctvaqhjzhutk...@mail.gmail.com, Mich el de Nostredame writes: On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart jer...@mompl.net wrote: I battled for a few hours getting IPv6 rDNS to work. The following tool proved to be quite helpful: http://www.fpsn.net/?pg=toolstool=ipv6-inaddr Just in case anyone else would run into similar problems. It's not as straightforward as IPv4 rDNS. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html Forgive me if this is a stupid question. I am curious that if BIND ever tried to make the DB file easier to operate under pure text-based environment. For example, allow something like following format inside zone file, $ORIGIN 1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. 48ff:fe35:d1bc PTR server.example.com. Firstly you don't have enough bits for a IPv6 address specified and secondly how would you distingish that from wanting the following? 48ff:fe35:d1bc.1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. PTR server.example.com. What would be the point of wanting that? It's not a legitimate ip6.arpa name. While I realize BIND will dutifully parse it in its current state and happily await a query for that particular name, it's not a legitimate ip6.arpa entry and no such query is going to arise from anything other than an error or abuse. In other words, while it is syntactically within the bounds of the RFC, it is semantically useless. If you feel like writing a $6REVERSE directive please go ahead. We would be happy to accept such a patch. I would however make it take full IPv6 addresses and also take prefix syntax ((prefixlen % 4) == 0, as only nibble boundaries make sense) and allow $ORIGIN to be specified. e.g. $6REVERSE fd78:8413:830:1::/64 SOA $6REVERSE fd78:8413:830:1::/64 NS $6REVERSE fd78:8413:830:1::/64 NS $6REVERSE fd78:8413:830:1::48ff:fe35:d1bc PTR server.example.com. $6REVERSE $ORIGIN fd78:8413:830:1::/64 @ SOA ... @ NS ... @ NS ... one could make it more general and do both IPv4 and IPv6 ($REVERSE). I agree that a $REVERSE directive would be a better solution. (v4 and v6) Owen
Re: IPv6 fc00::/7 — Unique local addresses
On Mon, 2010-11-01 at 20:03 -0700, Owen DeLong wrote: Interesting... I guess controlling your own internet fate hasn't been a priority for the companies where you've worked. Not one of my clients or the companies I have worked for has even given a second thought to approving the cost of address space once I presented the tradeoffs of PA vs. PI. You know how you complained when someone moved the discourse to residential when you mentioned enterprise and to enterprise when you mentioned residential? At least I think it was you. Well, you're doing it now :-) It's not a one size fits all situation. There is no problem with some people (typically enterprise types) being concerned about PI vs PA and going one way, and someone else (typically residential types) not being concerned about it and going another way. It's not really about size, it's about the needs of the particular organisation (with residential users just being very small organisations). The fees are not there to keep routes down. The fees are there to help the RIR recover the cost of maintaining the RIR and processing the application. Whatever; a useful side effect of the fees is that they provide a barrier to the uptake of PI by smaller organisations. Only those who can justify the cost of PI (in whatever terms that make sense to them) will go that way, and that will probably not be the many millions of residential users, who will be quite happy to use PA. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 rDNS
In message 7e9af5e9-7b3a-4767-a1d3-8eab64031...@delong.com, Owen DeLong write s: On Nov 1, 2010, at 4:40 PM, Mark Andrews wrote: =20 In message = aanlktinumzyp9qe0i5phyz72al3xyctvaqhjzhutk...@mail.gmail.com, Mich el de Nostredame writes: On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart jer...@mompl.net = wrote: I battled for a few hours getting IPv6 rDNS to work. The following = tool proved to be quite helpful: http://www.fpsn.net/?pg=3Dtoolstool=3Dipv6-inaddr Just in case anyone else would run into similar problems. It's not = as straightforward as IPv4 rDNS. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html =20 Forgive me if this is a stupid question. =20 I am curious that if BIND ever tried to make the DB file easier to operate under pure text-based environment. For example, allow something like following format inside zone file, =20 $ORIGIN 1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. 48ff:fe35:d1bc PTR server.example.com. =20 Firstly you don't have enough bits for a IPv6 address specified and secondly how would you distingish that from wanting the following? =20 48ff:fe35:d1bc.1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. PTR = server.example.com. =20 What would be the point of wanting that? The point is that you are CHANGING the meaning of something that already exists. It's not a legitimate ip6.arpa name. Why not? It's a perfectly legal name in the DNS. While I realize BIND will dutifully parse it in its current state and happily await a query for that particular name, it's not a = legitimate ip6.arpa entry and no such query is going to arise from anything other than an error or abuse. In other words, while it is syntactically within the bounds of the RFC, it is semantically useless. How do you know I don't have a use for it? If you feel like writing a $6REVERSE directive please go ahead. We would be happy to accept such a patch. I would however make it take full IPv6 addresses and also take prefix syntax ((prefixlen % 4) = =3D=3D 0, as only nibble boundaries make sense) and allow $ORIGIN to be = specified. =20 e.g. $6REVERSE fd78:8413:830:1::/64 SOA $6REVERSE fd78:8413:830:1::/64 NS $6REVERSE fd78:8413:830:1::/64 NS $6REVERSE fd78:8413:830:1::48ff:fe35:d1bc PTR server.example.com. =20 $6REVERSE $ORIGIN fd78:8413:830:1::/64 @ SOA ... @ NS ... @ NS ... =20 one could make it more general and do both IPv4 and IPv6 ($REVERSE). =20 I agree that a $REVERSE directive would be a better solution. (v4 and = v6) Owen =20 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 fc00::/7 — Unique local addresses
On Nov 1, 2010, at 5:23 PM, Karl Auer wrote: It's not a one size fits all situation. Right. There are folks who are more than happy (in fact demand) to pay the RIRs for PI space and pay their ISPs to get that space routed. There are (probably) folks who are perfectly happy with PA and accept that they'll need to renumber all their devices and change all their configs where there are IPv6 literals. But my impression is that there are more people who want to minimize the costs associated with PI _and_ with renumbering, hence PA+ULA+NAT66. As far as I can tell, the cost/benefit calculations here isn't significantly different from what it was with IPv4 (96 bits, no magic). Whatever; a useful side effect of the fees is that they provide a barrier to the uptake of PI by smaller organisations. Are those fees that much more of a deterrent than what ISPs will charge to route the PI space? Only those who can justify the cost of PI (in whatever terms that make sense to them) will go that way, and that will probably not be the many millions of residential users, who will be quite happy to use PA. My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... Regards, -drc
RE: IPv6 fc00::/7 - Unique local addresses
My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... That claim seems to be unsupported by current experience. Please elaborate. Nathan
Re: IPv6 fc00::/7 - Unique local addresses
On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote: My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... That claim seems to be unsupported by current experience. Please elaborate. Currently, most residential customers have PA+NATv4, where the CPE provides the public IPv4 address to the NATv4 box (which might be the same box as the CPE) via DHCP (or PPPoE). As such, all internal devices are shielded from all renumbering events. In a NATless PA world, all devices will need to be renumbered on a change of provider. While in theory, address lifetimes and multiple addresses should reduce the impact renumbering might have, I will admit some skepticism that renumbering IPv6 providers will be sufficiently transparent as customers are used to with IPv4 PA+NATv4. Perhaps I am wrong. Regards, -drc
Re: IPv6 fc00::/7 - Unique local addresses
On Tue, Nov 2, 2010 at 00:58, David Conrad d...@virtualized.org wrote: On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote: My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... That claim seems to be unsupported by current experience. Please elaborate. Currently, most residential customers have PA+NATv4, where the CPE provides the public IPv4 address to the NATv4 box (which might be the same box as the CPE) via DHCP (or PPPoE). As such, all internal devices are shielded from all renumbering events. In a NATless PA world, all devices will need to be renumbered on a change of provider. While in theory, address lifetimes and multiple addresses should reduce the impact renumbering might have, I will admit some skepticism that renumbering IPv6 providers will be sufficiently transparent as customers are used to with IPv4 PA+NATv4. Perhaps I am wrong. No average residential user should ever see or configure an IPv6 address; all the vendors are using zeroconf etc. to avoid it at all costs. If it was all autoconfigured in the first place, there's no reason autoconfiguration shouldn't be able to renumber it. -Ben
