DNS Problems on Saturday Night?
Forgive me for not having more technical information about this issue. Beginning sometime around 4:00 PM MST on Saturday, I started seeing horrible slowness on my home Internet connection through Comcast, and I also noticed that I was seeing numerous timeouts on DNS lookups. At the same time, a friend of mine who also uses Comcast was seeing the same thing. Approximately a third of my DNS lookups were timing out. That alone would be fairly easily explainable. However, our DNS servers at work also were having a really bad time trying to resolve external addresses. One server uses a Sprint circuit and the other server uses a Time Warner Telecom circuit, but they both point to UltraDNS. This strange behavior continued until roughly 9:00 PM MST and then the DNS problems cleared up both at home and at work. I haven't seen anyone else mention it yet but was there some sort of fairly large DNS problem for a few hours on Saturday? I don't know enough about DNS to know what form that problem might take. At this point I'm assuming it was just one of those things but I'm curious to know if the problem was more widespread. Regards, John --
British Telecom to buy Infonet
British Telecom will acquire Infonet Services in a deal worth $965 million, BT said Monday. http://news.com.com/British+Telecom+to+buy+Infonet/2100-1037_3-5442816.html?tag=cd.top - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
RE: British Telecom to buy Infonet
: From: Fergie (Paul Ferguson) : Date: Mon Nov 08 14:05:49 2004 : : British Telecom will acquire Infonet Services in a deal worth $965 : million, BT said Monday. : : http://news.com.com/British+Telecom+to+buy+Infonet/2100-1037_3-5442816.html?tag=cd.top I wonder if they'll do any better than CW did with Digital Island and Exodus. If not, my complete condolences go out to the Infonet employees. Looks like the investors think they will: http://finance.yahoo.com/q/bc?s=INt=5dl=onz=mq=lc= scott
Important IPv6 Policy Issue -- Your Input Requested
I would like to bring to the attention of Nanog an IPv6 policy issue that I think is slipping under the radar right now. The IETF IPv6 working group is considering two proposals right now for IPv6 private networks. Think RFC-1918 type space, but redefined for the IPv6 world. Those two drafts can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt These drafts came up in the ARIN meeting, and I posted my analysis of the problems with both at: http://www.arin.net/mailing_lists/ppml/2849.html I will post a very brief summary of my objections, for the first (unique-local): - I believe the math is wrong on the rate of collisions, primarily because it assumes in a large organization there is a central coordination function to pick and distribute these addresses. However, since the whole point of unique local addresses is that there need be no coordination, I can easily see a case where a large conglomerate (Ford, GE, whatever) coming together with another will have both sides bringing hundreds, if not thoundsands of prefixes to the table as each division or other subgroup picks their own. - I think the likelyhood people will use the suggested hash methods to pick addresses is extremely low. People will either pick human friendly (1, 2, 3, 4, etc) or treat the space more like CIDR (where there is central delegation), both of which move the likelyhood of collision to near 1. In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today. The second proposal (ula-central) is much more dangerous. - It is not good engineering to give something away for free with no method of recovery, even if that resource is plentiful. - The IETF should not be creating a new worldwide RIR. - The IETF should not be dictating fees (free). (more to the point, a worldwide RIR, with the language and other issues will be expensive, yet it has no method of income) - Since this is a free method of globally unique space it has a high likelyhood of being routed on portions of the public internet. Indeed, this problem was quickly dismissed by the authors (see http://www1.ietf.org/mail-archive/web/ipv6/current/msg03848.html), who completely missed the boat. It's not the rich who would demand their prefix be routed, but the poor. We already have situations where parts of Africa and Asia claim the fees for IP space are too high. If they had access to free global space they would jump on it, and later if the rest of the world wanted to contact that region they would almost certainly have to route it as well. - The ownership should be private, yet the reason for a registry is to verify ownership and prevent hoarding. I'm not sure how those are combatable. - I think the IPv6 groups continue in their fantasy that people will manage multiple, complete overlay networks to fix numbering issues. More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet. Since this is a list of providers, I encourage you to read the drafts, and submit your comments to the working group. The information for the working group is at http://www.ietf.org/html.charters/ipv6-charter.html, and includes their mailing list archives and information on how to subscribe and/or post. Even if you disagree with me, much like voting the important thing is that you voice your opinion. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpxra1uPC1XO.pgp Description: PGP signature
Re: Important IPv6 Policy Issue -- Your Input Requested
On 8 Nov 2004, at 14:25, Leo Bicknell wrote: In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today. Just out of interest, why do you think 1918-style space for v6 is needed? Joe
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote: Just out of interest, why do you think 1918-style space for v6 is needed? I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6. However, both of these proposals go well beyond how 1918 space works today, and both make promises of global uniqueness that are at best inappropriate, at worst a road to disaster. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp3IhQIqfPjN.pgp Description: PGP signature
Re: Important IPv6 Policy Issue -- Your Input Requested
On 8 Nov 2004, at 14:53, Leo Bicknell wrote: In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote: Just out of interest, why do you think 1918-style space for v6 is needed? I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.) I know of lots of networks that use RFC1918 addresses because of a (perceived, whatever) scarcity of IPv4 addresses, but presumably that argument doesn't necessarily follow for v6 networks, where ever customer site gets a /48. There is some value in RFC1918 addresses being used in v4 in cases where an extensive internal infrastructure is expensive to renumber, and PI addresses are not available. It is not clear that RFC1918 addresses are the only solution to this problem, though. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6. This sounds like a direct path to IPv6 NAT. However, both of these proposals go well beyond how 1918 space works today, and both make promises of global uniqueness that are at best inappropriate, at worst a road to disaster. Agreed, the proposals (as you outlined; I haven't read them) sound like they are full of holes. However, I worry about any natural assumption that RFC1918-like addresses are required for v6, simply because they are used in v4: it seems to me that the major reason to deploy v6 is to eliminate the very address scarcity that RFC1918 addresses are used to mitigate. Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing ;-) Joe
Re: Important IPv6 Policy Issue -- Your Input Requested
Would NAT be considered an application? :-) - ferg -- Joe Abley [EMAIL PROTECTED] wrote: I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.) -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Mon, Nov 08, 2004 at 03:08:13PM -0500, Joe Abley wrote: I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.) By applications I did not mean software programs but rather methods of designing networks. I know of lots of networks that use RFC1918 addresses because of a (perceived, whatever) scarcity of IPv4 addresses, but presumably that argument doesn't necessarily follow for v6 networks, where ever customer site gets a /48. A company may change providers often and want to use 1918 style space to not have to renumber part of the network, or may choose IPv6 NAT as superior to overlay networks. Indeed, I suspect overlay networks are going to be hugely unpopular. This sounds like a direct path to IPv6 NAT. While I do not encourage IPv6 NAT, anyone who thinks IPv6 will put the NAT Genie back in the bottle is smoking some serious crack. Lots of people like NAT for lots of reasons, and I am 100% positive there will be IPv6 NAT used by a lot of people. One obvious use if these proposals pass is to use your non-routable global unique prefix internally and NAT at the borders. Since a lot of people think this is effective security, I think it will be a common configuration. Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing ;-) Many people share your opinion, and I think it is a good one to voice. That said at the end of the day most engineers are going to treat IPv6 as IPv4 with bigger addresses. I know most of the IPv6 proponents just wrote me off as a loon by saying that, but I do believe it's reality and you need look no further than the existing test networks to see that it's the case. People who have become used to CIDR, and NAT and such aren't going to forget those idea's because someone told them rigid boundaries are good and you don't need private space anymore. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Important IPv6 Policy Issue -- Your Input Requested
On Mon, 8 Nov 2004, Joe Abley wrote: Perhaps the non-availability of RFC1918 addresses would provide a useful incentive for future v6 network architects to install globally-unique addresses on all hosts? Perhaps I am the only one that thinks that would be a good thing ;-) You're definitely not alone with this feeling :-). It's just that there are some conceivable scenarios, like intermittent connectivity (+local connectivity during the outage) which seems to call for either local addressing or global PI addressing, and the latter has not gained much momentum.. IPv6 site multihoming for bigger enterprises is also one area where (at the moment) something like ULAs have some questionable uses. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Important IPv6 Policy Issue -- Your Input Requested
Hello, I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space. Wouldn't 0::10.0.0.0/104, 0::192.168.0.0/112, and 0::172.16.0.0/116 (or whatever the appropriate masks would be) all function as v6 addresses with exactly the same properties at the current RFC1918 space? Eric :)
Re: Important IPv6 Policy Issue -- Your Input Requested
I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space. because there is not enough v6 address space? because we like nats? because we think we can't get space? randy
Re: Important IPv6 Policy Issue -- Your Input Requested
At 02:36 PM 11/8/2004, you wrote: On 8 Nov 2004, at 14:25, Leo Bicknell wrote: In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today. Just out of interest, why do you think 1918-style space for v6 is needed? Well, you asked the original poster, but since you asked publicly, I'll answer with my reasons. Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments. Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too. Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside. Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband router (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use.
Content Delivery Networks/GSLB
Hello, I am wondering if somebody can point me to the links where I can found information about Content Delivery Network Solutions used in the market today. I need to know about the technology and how the solution/company (such as Akamai) caters its customers. Do they mirror the content across their server's network? If this is the case then how a request is directed to the closest and lightly loaded server on Internet? There are other hardware (GSLB on F5, BigIP and Cisco CSS) and software (ultraDNS) solutions in the market as well but its difficult to relate those with a CDN solution such as of Akamai's or others. Does anybody have experience with F5 or BigIP GSLB solutions? I would appreciate if somebody can help me out here as well. Thanks, Huda
Re: Important IPv6 Policy Issue -- Your Input Requested
On Mon, Nov 08, 2004 at 01:04:28PM -0800, Randy Bush wrote: I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space. because there is not enough v6 address space? because we like nats? There's no PI (yet) for IPv6, so NAT becomes necessary again. People don't like to give up the independence they have in IPv4 world. because we think we can't get space? For non-ISPs this is fact, given that there is no PI (yet). ISPs are allowed to multihome and have their independent address space, other's are told to be happy with vendor lock-in. IPv6 won't fly like that. But that's no news, but still heads are sticking deeply in the sandbox, unfortunately. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: Important IPv6 Policy Issue -- Your Input Requested
On Mon, Nov 08, 2004 at 03:46:05PM -0500, Daniel Senie wrote: Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. inet6num: 2001:0DB8::/32 netname: IPV6-DOC-AP descr:IPv6 prefix for documentation purpose [...] remarks: This address range is to be used for documentation remarks: purpose only. For more information please see remarks: http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband router (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. I don't see that this is hard. The box will get a /48 from the ISP's DHCPv6 server (or whatever is used for that) and re-use subnets for that for inside routing. Like simply the first /64, and doing router advertisements on the inside ethernet for this subnet to allow autoconfig of the hosts of the home LAN. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: Important IPv6 Policy Issue -- Your Input Requested
On Mon, 8 Nov 2004, Daniel Senie wrote: Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments. Sure, though see #3 which can be stolen for lab usage as well. Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too. For serious usage, I don't think the money involved is a major issues. Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside. Already done, 2001:db8::/32 is set aside for documentation. Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband router (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use. Setting up local v6 addressing for this reason seems like a bad idea because there is no NAT and no global connectivity, so the box will need some automated configuration protocol in any case. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Important IPv6 Policy Issue -- Your Input Requested
I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never understood why we needed a new set of RFC1918-like IPv6 space. because there is not enough v6 address space? because we like nats? There's no PI (yet) for IPv6, so NAT becomes necessary again. People don't like to give up the independence they have in IPv4 world. because we think we can't get space? For non-ISPs this is fact, given that there is no PI (yet). ISPs are allowed to multihome and have their independent address space, other's are told to be happy with vendor lock-in. IPv6 won't fly like that. But that's no news, but still heads are sticking deeply in the sandbox, unfortunately. let me see if i understand. you propose a technical cluster bleep with which we are already horrifyingly familiar to fix an administrative problem? have i got it right? randy
Re: k.gtld-servers.net 0wned?
On 8-nov-04, at 11:20, Suresh Ramasubramanian wrote: Apparently not, as this isn't the right address for k.gtld-servers.net. Well - how / where did you get an IP in Hanaro Telecom, Korea space for k.gtld-servers.net? DNS cache poisoned or something? Apparently. I don't manage the box in question so I don't know any details about how it happened.
Re: Important IPv6 Policy Issue -- Your Input Requested
In message [EMAIL PROTECTED], Leo Bicknell writes: In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wr= ote: Just out of interest, why do you think 1918-style space for v6 is=20 needed? I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6. However, both of these proposals go well beyond how 1918 space works today, and both make promises of global uniqueness that are at best inappropriate, at worst a road to disaster. There are cetainly main uses; one can quibble over whether or not they're good... That said, see draft-ietf-ipv6-unique-local-addr-07.txt In not very different form, it's likely to be approved soon by the IESG. --Steve Bellovin, http://www.research.att.com/~smb
Update to Strange DNS Issue
I have some additional information that's making me think what I saw on Saturday was just a coincidence. We have two DNS servers that were unable to resolve external addresses beginning around 4:00 PM MST on Saturday, but I found out that they both had just been rebooted. We use some version of BIND on Solaris 9 and it was verified that named was running, yet external names would not resolve for a few hours. External names began to resolve in a few hours with no intervention on our part. BIND gurus, any idea why this might have occurred? If named is running and internal names resolve *and* there are no problems with Internet connectivity, what might cause external lookups to timeout for a few hours only to resolve spontaneously? It seems a little strange and I'm sure there's some important information that I'm missing that would make it all makes sense. Thanks, John --
Re: Content Delivery Networks/GSLB
On Mon, 8 Nov 2004, M. Huda wrote: : market today. I need to know about the technology and how the : solution/company (such as Akamai) caters its customers. Do they mirror : the content across their server's network? If this is the case then : how a request is directed to the closest and lightly loaded server on : Internet? This is the proprietary part of the technology that produced law suits with Akamai. Here's Akamai's sound byte: Host-to-Host Adaptive Routing Protocol (HHARP). HHARP detects Internet congestion and determines the best route to move content between a customer's origin servers and the edge of the Internet, thereby avoiding performance problems. Don't forget that Akamai is not the only one. Footprint, which went from Sandpiper - Digital Island - Cable and Wireless - Savvis, is the product on the other side of the lawsuit. I don't know if it was ever resolved fully... scott
Re: Important IPv6 Policy Issue -- Your Input Requested
On Mon, Nov 08, 2004 at 02:25:00PM -0500, Leo Bicknell wrote: More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet. Well, thinking about the enterprise for a change might be a good idea, as the Enterprise markets are the one paying most of the ISPs in the end. And with the ISP-centric approach of the current address policies there is absolutely no chance IPv6 will ever make it to the big market. As long as I can neither multihome nor NAT my network, I have no chance to be independant of a provider. As the provider business itself is extremely unstable that is something no enterprise can possibly want. So there must be a way to be provider independent on my network, otherwise I am pretty much doomed. I do hate NAT and I think it is a major pain. Providers decided (they are the ones active in the working groups on Address policies, remember?) that their customers should not be able to be multihomed, because the equipment to handle this is too expensive, so I at least want a globally unique private address, so I do not have to double NAT, when I connect my network to some customers or suppliers network. I agree, that the proposed solutions are not perfect, but they at least give enterprise network admins the chance to do the right thing. With RfC1918 (shall we call it site local addressing, maybe?) I am almost forced to use the same address space as my customers and suppliers do. The two approaches mentioned only will give collisions, when one side uses them inappropriately. I think having the chance to do it right is better then not having it. Nils
Re: Important IPv6 Policy Issue -- Your Input Requested
On 8-nov-04, at 20:25, Leo Bicknell wrote: I will post a very brief summary of my objections, for the first (unique-local): - I believe the math is wrong on the rate of collisions, primarily because it assumes in a large organization there is a central coordination function to pick and distribute these addresses. However, since the whole point of unique local addresses is that there need be no coordination, I can easily see a case where a large conglomerate (Ford, GE, whatever) coming together with another will have both sides bringing hundreds, if not thoundsands of prefixes to the table as each division or other subgroup picks their own. Well, if they can manage to interconnect all those networks a tiny amount of coordination isn't too much to ask for. Also, with the proper hashing this shouldn't be much of a problem even without coordination. Yes, no coordination and bad hashing won't work, but guess what: don't do that. - I think the likelyhood people will use the suggested hash methods to pick addresses is extremely low. People will either pick human friendly (1, 2, 3, 4, etc) or treat the space more like CIDR (where there is central delegation), both of which move the likelyhood of collision to near 1. In the end I think we need 1918 style space, and that it should simply be set aside as a large block and expected to never be useful in the context of other organizations, just like 1918 space is today. Your argument is that people are going to be stupid so we should skip ahead and give them the result of their stupidity. Now obviously there will be people who do it the stupid way, but at least unique site locals allow the people who don't do it the stupid way certain benefits. I don't see how this can ever be a bad thing. Also, you can still use the original IPv6 site local space, as I don't see it being reused for something else any time soon. But if you do, you'll probably discover that there is a reason why the IETF decided to deprecate those. - It is not good engineering to give something away for free with no method of recovery, even if that resource is plentiful. So we should play telco and sell a service that is so cheap that the users are basically only paying for the billing? (= metered local calls) - Since this is a free method of globally unique space it has a high likelyhood of being routed on portions of the public internet. Indeed, this problem was quickly dismissed by the authors (see http://www1.ietf.org/mail-archive/web/ipv6/current/msg03848.html), who completely missed the boat. It's not the rich who would demand their prefix be routed, but the poor. That's nice. But it simply can't be done for any significant number of PI prefixes. That's why we're going through so much trouble to create a multihoming mechanism that doesn't kill the routing system. Since this is a list of providers, I encourage you to read the drafts, and submit your comments to the working group. The information for the working group is at http://www.ietf.org/html.charters/ipv6-charter.html, and includes their mailing list archives and information on how to subscribe and/or post. Even if you disagree with me, much like voting the important thing is that you voice your opinion. I suggest that everyone who is willing to spend the time, also looks into the site local debates that have plagued the IETF in recent years.
RE: Important IPv6 Policy Issue -- Your Input Requested
-Original Message- From: Eric Gauthier [mailto:[EMAIL PROTECTED] Subject: Re: Important IPv6 Policy Issue -- Your Input Requested Hello, I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never Nor have I ... I'm just starting to look at IPv6 now This seems like a good discussion to jump in on though. :) understood why we needed a new set of RFC1918-like IPv6 space. Wouldn't 0::10.0.0.0/104, 0::192.168.0.0/112, and 0::172.16.0.0/116 (or whatever the appropriate masks would be) all function as v6 addresses with exactly the same properties at the current RFC1918 space? If the existing RFC1918 space will exist in IPv6 as described above, that can, presumably, be used in the same way existing 1918 space is. For instance, as non-routable loopback addresses for routers, switches, etc. Correct? Or is IPv6 NAT batter suited for this in the future? Eric :) -- Jason Frisvold Penteledata
Re: Important IPv6 Policy Issue -- Your Input Requested
At 3:37 PM -0500 11/8/04, Steven M. Bellovin wrote: In That said, see draft-ietf-ipv6-unique-local-addr-07.txt In not very different form, it's likely to be approved soon by the IESG. With due respect to my colleague Steve, I think this depends on what not very different from means. I'm currently holding a DISCUSS on this document, for reasons related to the ones Leo raised. In particular, I strongly believe that allocating this space: This document only allocates the prefix (FC00::/8) for centrally assigned local IPv6 addresses. The characteristics and technical allocation requirements for centrally assigned Local IPv6 addresses will be defined in a separate document. is very unwise. One of the problems with site local was the prefix got allocated but the work on what it would mean never got full community support. Doing the same thing twice just strikes me as dumb. I have some other very serious concerns about the extent to which the document presumes that these will be routed between ASes without recognizing that this means they could become the v6 swamp. So this discussion is *not* over, and I believe comments from operators to the WG and to the IESG are still very appropriate. regards, Ted Hardie
Re: Important IPv6 Policy Issue -- Your Input Requested
is very unwise. One of the problems with site local was the prefix got allocated but the work on what it would mean never got full community support. Doing the same thing twice just strikes me as dumb. do you mean 1918 twice or site-loco twice? both are stoopid. either is stoopid. it'll be interesting to see if the ivtf does it again. stick to your guns. randy
Re: Important IPv6 Policy Issue -- Your Input Requested
In a message written on Mon, Nov 08, 2004 at 10:46:48PM +0100, Iljitsch van Beijnum wrote: Well, if they can manage to interconnect all those networks a tiny amount of coordination isn't too much to ask for. Also, with the proper hashing this shouldn't be much of a problem even without coordination. Yes, no coordination and bad hashing won't work, but guess what: don't do that. It is too much to ask for, because you assume it's one company day one. What happens when AOL and Time Warner merge? There was no chance of coordination before that. Or how about Cisco? They buy what, 100-200 companies a year? My problem is that even with good hashing it doesn't take long for there to be a collision. And once there is a single collision the whole system is suspect. It's the promise of if you do this extra work you'll never have to renumber without delivering. Your argument is that people are going to be stupid so we should skip ahead and give them the result of their stupidity. Now obviously there will be people who do it the stupid way, but at least unique site locals allow the people who don't do it the stupid way certain benefits. I don't see how this can ever be a bad thing. No, my argument is that it only takes a few stupid people to make this entire system not work at all. Since the draft seems to promise it will work it is misleading people. Indeed, I have proof the IPv6 crowd realizes this won't work at all, and it's the other draft. If this draft had a chance of working then there would be no need to create a central registry to guarantee unique addresses. The very existence of that draft shows some people realize this method will not work. - It is not good engineering to give something away for free with no method of recovery, even if that resource is plentiful. So we should play telco and sell a service that is so cheap that the users are basically only paying for the billing? (= metered local calls) No. My argument is not about money. In this system anyone can get something for free anytime they want. Lose your address block? Make it unusable for some purpose (eg, blacklisted)? Just want a second (third, fourth, millionth) block, just go get it. Get a block, then die? Well, no one else can ever use your personal block. If you get a personal block, then die, no one else can ever reuse that block. Every failed dot-com, that's address space we'll never be able to use again. I realize there is a lot of space, but this proposal really seems to ask the question how fast can we waste space if we try, which is very dangerous in my opinion. That's nice. But it simply can't be done for any significant number of PI prefixes. That's why we're going through so much trouble to create a multihoming mechanism that doesn't kill the routing system. Bah, hand-waving that makes no sense. There are 33,000 allocated ASN's today. Give each one a PI prefix (however they might get it). That's 33,000 routes. Given my routers are fine with 140,000 now, and are being tested in labs to well over 1 million and I fail to see the issue. Let's assume they all have two PI prefixes for load balancing, ok, we're at 66,000, still no problem. More to the point, if most network admins have the choice of running a full overlay network and updating software on every end host to be more complex to make it understand the overlay networks or puting a few more prefixes in the routing table and upgrading your router I bet they will all pick the latter. The problem is not routing PI blocks for all the existing ISP and even companies. The problem is routing blocks for individuals. If ISP's fall to pressure to route these prefixes between themselves (after all, they are globally unique, so what's the harm?) and then you inject individual's prefixes into the table you now have a melt down. As with most system failures it takes multiple steps. However, I think these steps are likely. ISP's in Asia have complained forever that they don't get a fair share of the space. Well, here they can take, take, take and use as much as they need. ISP's in Africa have complained space costs too much (ARIN's fees, though low by US standards are several years sallary in some countries), and want a way around it. If those groups used this space even only internally at first between each other (after all, the purpose is to allow routing between organizations, just not to the global internet) eventually there will be great pressure to add them to the global table. It will be phrased as UUNet won't accept prefixes from all of Asia or similar. Then we end up having to accept them with none of the controls the RIR system puts in place for setting policy or anything else. Prefixes will instead be randomly assigned worldwide out of a single /7. Distilled down the proposal makes no sense. 1 You can have globally unique addresses. 2 You can use them between organizations. a If your
Re: Important IPv6 Policy Issue -- Your Input Requested
In message [EMAIL PROTECTED], Ted Hardie writes: At 3:37 PM -0500 11/8/04, Steven M. Bellovin wrote: In That said, see draft-ietf-ipv6-unique-local-addr-07.txt In not very different form, it's likely to be approved soon by the IESG. With due respect to my colleague Steve, I think this depends on what not very different from means. I'm currently holding a DISCUSS on this document, for reasons related to the ones Leo raised. In particular, I strongly believe that allocating this space: This document only allocates the prefix (FC00::/8) for centrally assigned local IPv6 addresses. The characteristics and technical allocation requirements for centrally assigned Local IPv6 addresses will be defined in a separate document. is very unwise. One of the problems with site local was the prefix got allocated but the work on what it would mean never got full community support. Doing the same thing twice just strikes me as dumb. I have some other very serious concerns about the extent to which the document presumes that these will be routed between ASes without recognizing that this means they could become the v6 swamp. So this discussion is *not* over, and I believe comments from operators to the WG and to the IESG are still very appropriate. Thanks. Ted is quite right, of course. --Steve Bellovin, http://www.research.att.com/~smb
Re: Important IPv6 Policy Issue -- Your Input Requested
At 04:17 PM 11/8/2004, Pekka Savola wrote: On Mon, 8 Nov 2004, Daniel Senie wrote: Reason #1: Lab use. People should NEVER, EVER pick random space from public space for doing experiments in the lab. Sooner or later something leaks, and people get really honked off. This happened a LOT with IPv4, prior to RFC 1597 and 1918. Let's not repeat the same mistake, and make sure people have a specific place to get address space from for experiments. Sure, though see #3 which can be stolen for lab usage as well. I'm not sure it's a great idea to tie these together, based on what I've seen in the past. Reason #2: Disjoint networks: though we may think the only reason to use the IP protocol suites (v4 or v6) is to connect to other places in the world, there are networks which do not (or are at least not supposed to) intersect with the public Internet. Address allocation policies are based on what space you're going to advertise, and registries want money for the space. Networks that are not connected should be able to use the IP protocol suites too. For serious usage, I don't think the money involved is a major issues. Translation: only rich companies are entitled. Smaller businesses are not entitled to space, and not entitled to use IPv6. For offline use, I guess IPv4 will be the permanent solution. Reason #3: A separate set of blocks should be set aside for use ONLY in documentation. Otherwise people use whatever addresses are in the examples in their router manuals and leak packets. I was seeing RIP packets claiming to come from 128.185/16 the entire time in the 1990's I worked at Proteon. Of course implementing BCP38 would help with the misconfigured user networks that were spewing that stuff. Nonetheless, documentation examples are a legitimate case for which space should be set aside. Already done, 2001:db8::/32 is set aside for documentation. Good. Reason #4: Initial configuration of equipment which lacks a console port. I know, you're going to suggest the use of autoconfiguration mechanisms or DHCP. That's sometimes hard, for example in the case of a broadband router (home gateway) box that's going to be the DHCP server, print servers, and other such equipment. Having some block for this (or just use some subnet of the RFC-1918-like space) is a reasonable use. Setting up local v6 addressing for this reason seems like a bad idea because there is no NAT and no global connectivity, so the box will need some automated configuration protocol in any case. Autoconfiguration is probably not the answer to every piece of routing gear or every embedded system built. I guess designers will need to continue installing a serial port on every device to ensure there is some way to get into the device and configure it if autoconfiguration isn't able to conquer the world.
Re: Important IPv6 Policy Issue -- Your Input Requested
Leo Bicknell wrote: I would like to bring to the attention of Nanog an IPv6 policy issue that I think is slipping under the radar right now. The IETF IPv6 working group is considering two proposals right now for IPv6 private networks. Think RFC-1918 type space, but redefined for the IPv6 world. Those two drafts can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-00.txt These drafts came up in the ARIN meeting, and I posted my analysis of the problems with both at: http://www.arin.net/mailing_lists/ppml/2849.html I dont understand much about ipv6. Yes I am now internationaly recognized for the ipv6 noob and loser that I am. What I do know is that ostensibly we need it due to address shortage. Its also easy to see that a entire trainload of new technology has been hitched up to that wagon. No surprise that people are not pulling eachother down in their haste to jump on it To all of us happily using ip4 does ipv6 offer anything valuable other than more space? Do net admins who dread troubleshooting real networks with unrecognizable and unmemorizable addresses exist? Maintaining configuration where you will never spot a fat fingered address ever? And I mean even those who dont run Real Networks (TM) All those people who curse vendors who make them put in 128 bit key software unlock codes, raise your hands. (I actualy memorized one or two of them after four years) Is anybody keeping track of what percentage of ipv6 has already been spoken for in some way and what percentage of the categories spoken for are utilized in any way? Yes I know. 128 bits address space is infinite! You couldnt run out if you tried! (~100 more /7 proposals like the one mentioned in parent and ipv6 is in trouble)
Re: Important IPv6 Policy Issue -- Your Input Requested
On Mon, Nov 08, 2004 at 05:56:58PM -0500, Joe Maimon wrote: To all of us happily using ip4 does ipv6 offer anything valuable other than more space? Depends on who you are. Do net admins who dread troubleshooting real networks with unrecognizable and unmemorizable addresses exist? Actually, I find IPv6 addresses much more memorizable as you can give your addressing plan hierarchical structure and don't get about arbitrary numbers like in v4 CIDR where you don't even see where a subnet starts and ends. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: Important IPv6 Policy Issue -- Your Input Requested
I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.) There are a number of good and reasonable uses for RFC1918 addresses. Just assume a individual/business/corporate LAN with client/server applications and statically configured ip numbering. RFC1918 addresses are perfect. NAT allows this network to be connected through any provider(s) to the Internet. There is no risk of collision of the internal address with publically routed addresses. To do without RFC1918 type address space it expect to a. Obtain unique, permanent address space for personal/business/corporate use b. Receive this unique, permanent address space at no cost c. Have this unique address space routed via any provider of my choosing Adi
Re: DNS Problems on Saturday Night?
On Mon, 8 Nov 2004, John Neiberger wrote: Forgive me for not having more technical information about this issue. Beginning sometime around 4:00 PM MST on Saturday, I started seeing horrible slowness on my home Internet connection through Comcast, and I also noticed that I was seeing numerous timeouts on DNS lookups. At the same time, a friend of mine who also uses Comcast was seeing the same thing. Approximately a third of my DNS lookups were timing out. I had lots of problems with Comcast DNS over the weekend. The Comcast network status said some undefined network maintenance was occuring. When I used a different provider at the same time, I didn't see any problems. So I just assumed it was the usual Comcast gremlins and used an alternate provider for a while. By Sunday whatever the network maintenance or problem was seemed to have cleared up.
Re: Important IPv6 Policy Issue -- Your Input Requested
On 8 Nov 2004, at 18:18, Adi Linden wrote: I don't know of any applications that require RFC1918 addresses to be deployed. (Clearly, this is not to say there are none.) There are a number of good and reasonable uses for RFC1918 addresses. [one reasonable use] Yes, I mentioned that in the paragraph following the one you quoted. There is more than one way to skin that cat, however, and not every way requires RFC1918 address analogues to be made available in v6. Joe
Re: Important IPv6 Policy Issue -- Your Input Requested
Hay, Daniel Roesen wrote: [...] Personally, I just wait for people to realize that they won't be able to force people into provider lock-in, allow one PI prefix per AS and THEN things can go off. With that, the global IPv6 table would be around 18k routes btw. As IPv4 and ASN are virtually unrestricted available today, I don't suspect any bigger growth rates in IPv6 land for ASNs and prefixes than in the IPv4 land. As such, I fail to see the problem with PI for IPv6 for a long long time to come. But that's just me silly. :-) ...not only you... Lower your filters, Resistance is futile. You will be flooded with /48s :- No, i mean, this issue/discussion is several years old now. I haven't seen any movement in either direction - pro or contra IPv6-PI (or less strict IPv6-BGP filters to be correct) throughout the last years. There are many good reasons why it's simply a matter of fact, that even if you start IPv6-PI now, the IPv6-BGP tables won't reach the currernt IPv4 size for the whole lifetime of IPv6, let alone that you always have to carry around the IPv4 tables for a lng time anyways, not to mention that current routers are already fast enough and have enough RAM for decades to come anyways (yes, 640k is enough for anyone :-). This is simply stuck and one of the more important issues, why IPv6 doesn't work out yet (like you said, It's less useful than IPv4). Believe it or not, there's a real world outside. We might not like it from a technical point of view, but we build networks for them to use it, so I don't even see the point about refusing IPv6-PI by anyone who wants to push IPv6-deployment. But anyways, this thread is about something different, about RfC1918-equivalents. This shouldn't be mixed up in first place, but I don't really like the idea of private IPv6 Network range either, because it means there will be IPv6-NAT with all the problems that NAT might cause, but there really might be SOME people who want to have it just like that. Same thing as above... if people just LOVE RfC1918 and NAT, they might not want to have IPv6 because it doesn't work with that. Again, believe it or not, the majority of people and even network-admins out there don't really care if a solution is the best for the community or the best from a scientific point of view, they just want it to be simple and working. ...and i always thought that IPv6 was build to be simple and working. And yes, I read multi6 WG. Sure, nice to have multi6 and new ideas, but i don't see them being implemented and useful until 2015 or so (no offencement, people of multi6 :-) Note: I don't say that new multihoming solutions are a wast of time, au contrair... but they _all_ won't replace the current (BGP-/PI-)multihoming solution in every case. -- = Sascha 'master' Lenz SLZ-RIPE [EMAIL PROTECTED] = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * =
Re: Content Delivery Networks/GSLB
I need to know about the technology and how the solution/company (such as Akamai) caters its customers. Do they mirror the content across their server's network? If this is the case then how a request is directed to the closest and lightly loaded server on Internet? There are other hardware (GSLB on F5, BigIP and Cisco CSS) and software (ultraDNS) solutions in the market as well but its difficult to relate those with a CDN solution such as of Akamai's or others. Does anybody have experience with F5 or BigIP GSLB solutions? I would appreciate if somebody can help me out here as well. The answer to such general questions is called know-how. Companies in business of selling products based on the know-how tend not to tell their competitors how that know-how works, since those companies spent millions of dollars developing that know-how from the paying the pointy-headed Ph.D.s to do theoretical work to spending enormous amounts of money on deployment. The way to benefit from the know-how without spending all your money on the pointy headed Ph.D.s is to buy/license/use it or hire a team or people who in exchange for something else (such as money, sex, suitcases of cocaine, F-18s) will either provide that know-how, develop a know-how or explain to whoever hires them that it is cheaper to buy the service. As far as F5 or BigIP go, they work just fine for website load-balancing. Alex
RE: Important IPv6 Policy Issue -- Your Input Requested
Just out of interest, why do you think 1918-style space for v6 is needed? If we could assign every entity who wanted one sufficient non-routable, globally unique space, we wouldn't need 1918-style space. There are, however, three problems with this approach: 1) It encourages massive waste. Perhaps so massive that we would run out of space. 2) There is a cost associated with assigning globally-unique space no matter how you do it. This cost could be too high for some application -- RFC-1918-style space is free. 3) There is a concern that some recipients of this globally-unique unroutable space might use political pressure to get that space routed. This could potentially lead to an explosion of the number of routes in the global table. However, there are huge advantages. Private networks could seamlessly overlay the Internet and each other where desired with no risk of a future merger causing a numbering conflict. I think the first and second problems are solvable. The third problem, however, may be the deal killer. It's a very realistic concern that the technologies we develop and promote can be designed to make things we consider bad easier or harder to do. Technologies can encourage cooperative interoperability or free riding, privacy or interceptability, and so on. DS
RE: Important IPv6 Policy Issue -- Your Input Requested
On Mon, Nov 08, 2004 at 02:25:00PM -0500, Leo Bicknell wrote: More to the point, it seems to me the working group is highly enterprise focused, and seems to want to give enterprises what they (think) they want with little concern for how it impacts the global Internet. Well, thinking about the enterprise for a change might be a good idea, as the Enterprise markets are the one paying most of the ISPs in the end. And with the ISP-centric approach of the current address policies there is absolutely no chance IPv6 will ever make it to the big market. Snip You bring up a very good point and one that is often ignored. The enterprise customers Do they understand IPv6 Do they want IPv6 Do they need IPv6 Are they writing IPv6 applications Right now there is no good reason for them to switch to ipv6 and they certainly aren't writing any apps for it. They are however waiting and hoping it doesn't happen.
RE: Important IPv6 Policy Issue -- Your Input Requested
2) There is a cost associated with assigning globally-unique space no matter how you do it. This cost could be too high for some application -- RFC-1918-style space is free. you want unique space but not pay for the administration of it. absolutely brilliant. 3) There is a concern that some recipients of this globally-unique unroutable space might use political pressure to get that space routed. This could potentially lead to an explosion of the number of routes in the global table. look, there are two camps o v6 space is effectively infinite and the routing table can handle 500k entries easy o v6 space is kinda small (sure wish they had done variable length), and we should worry about the routing table in the first case, let them eat cake and to hell with all this yakking. in the latter case, withdraw the allocations of golden space to special services, stop allocating monsterous /48s to ethernets when we know layer-2 does not scale, stop giving /32s to anyone who asks (or whatever the fashionable prefix of the week is, i can't keep track), etc. either this thing is big enough and gonna scale, or send the turkey back to the drawing boards. but don't add already well-known disasters on top of something in which you have insufficient faith to trust to scale well. randy
Status of FCAPS model? Useful? Obsolete?
Someone at Forrester research wrote an article in 2003 that said FCAPS was an obsolete model because it was conceived during a time when mainframes were in use. I haven't read the article but the premise of it seemed a bit overboard to me. Does the FCAPS model still hold currency among network managers/engineers today? Do the functional categories it uses make sense of the management activities of modern networks? Is there a set of activities that in and of itself warrants further categorization? For example, should project management be added to the model since most well run networks emanate from adherence to generally accepted project management processes? We can all think of examples where a piece of network technology does not map neatly into the OSI model. But because enough of what goes on in networking does map neatly to that model, it is still useful to refer to it. I believe the same is true with FCAPS. I see too that companies like Cisco still refer to it in some of their Networkers presentations. As I understand it, the purpose of the model is to outline the overarching categories of activities necessary for the successful management of a sizeable network. The ultimate impact of failing to manage these areas properly is loss of productivity, revenue or opportunity. Outside the realm of profitability, the FCAPS model is a teaching device whose purpose, like all models, is to explain phenomena which otherwise would be a confusing, jumbled mess. Does the study of FCAPS profit a person if they intend to manage well a network? Is there some better model worthy of study? If so, why? Sean had some comments on the shortcomings of FCAPS for carrier networks awhile back. Any fresh comments are welcome. Thanks, JM
Re: Important IPv6 Policy Issue -- Your Input Requested
To the end user of address space it is absolutely irrelevant how large the total space is or what the size of the routing table is. What matters is how much cost/effort you need to expend to get your address space, and what you need to use it for. A guarantee of global uniqueness has an unavoidable (and, in fact, quite significant) cost; some uses of address space don't require global uniqueness; therefore there will be a market demand for non-unique space. then let them make up addresses. oh, you mean they don't want to collide with global addresses? so they want nat? i though a major goal of v6 was no nat. again, you want you cake or want to eat it?
Re: Important IPv6 Policy Issue -- Your Input Requested
At 10:10 PM 11/8/2004, Randy Bush wrote: To the end user of address space it is absolutely irrelevant how large the total space is or what the size of the routing table is. What matters is how much cost/effort you need to expend to get your address space, and what you need to use it for. A guarantee of global uniqueness has an unavoidable (and, in fact, quite significant) cost; some uses of address space don't require global uniqueness; therefore there will be a market demand for non-unique space. then let them make up addresses. oh, you mean they don't want to collide with global addresses? so they want nat? i though a major goal of v6 was no nat. Is it SO hard for people to understand that it's possible today to use private address space and public address space in a network WITHOUT using NAT? In today's networks, printers do NOT need global addresses. Telephones which connect only to a PBX in a private network need not have public addresses. On those same networks, workstations and servers might have public addresses. We have these neat devices called routers that allow private address subnets and public address subnets to talk to one another WITHOUT NAT, within an enterprise network. There was a local scope addressing that some thought would fill this role, but then a bunch of folks decided that was a bad idea and shot it. Sounds like the documentation address block will fill the role of supporting telephones, printers, factory floor automation and other devices which do not (and in some cases SHOULD NOT) talk to the public Internet. Please make honest arguments, and stop insisting that private addressing == NAT. again, you want you cake or want to eat it? Is it SO hard to understand that some people actually wanted site local addressing? I guess it is. That's how at least some folks used RFC 1918...
Re: Important IPv6 Policy Issue -- Your Input Requested
[snip] I dont understand much about ipv6. Yes I am now internationaly recognized for the ipv6 noob and loser that I am. What I do know is that ostensibly we need it due to address shortage. Its also easy to see that a entire trainload of new technology has been hitched up to that wagon. No surprise that people are not pulling eachother down in their haste to jump on it I am not too sure about addr shortage and thus can't comment myself. But what we do know is that IPv6 provides a large amount of *subnets* and each subnet (minimum recommendation being /64) already contains lot more addrs than entire IPv4 space. So it could mean some new possibilities down the road (e.g. certain companies using ipv6 for product management, etc) as the technology changes. To all of us happily using ip4 does ipv6 offer anything valuable other than more space? Yes.. stateless autoconf by icmp and few others but I don't really care about those personally myself. Do net admins who dread troubleshooting real networks with unrecognizable and unmemorizable addresses exist? Maintaining configuration where you will never spot a fat fingered address ever? And I mean even those who dont run Real Networks (TM) Unmemorizable? I don't know about that one. I can memorize IPv6 addrs much faster and better than IPv4 addrs. I know it may sound like a paradox, but IPv6 addrs, once you get used to them, are neatly organized into TLA-NLA and all the way to Site level. All those people who curse vendors who make them put in 128 bit key software unlock codes, raise your hands. (I actualy memorized one or two of them after four years) Is anybody keeping track of what percentage of ipv6 has already been spoken for in some way and what percentage of the categories spoken for are utilized in any way? Yes I know. 128 bits address space is infinite! You couldnt run out if you tried! (~100 more /7 proposals like the one mentioned in parent and ipv6 is in trouble) Bad assumptions. -J -- James JunTowardEX Technologies, Inc. Technical Lead IPv4 and Native IPv6 Colocation, Bandwidth, [EMAIL PROTECTED] and Web Hosting Services in the Metro Boston area cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
RE: Status of FCAPS model? Useful? Obsolete?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 8:52 PM To: [EMAIL PROTECTED] Subject: Status of FCAPS model? Useful? Obsolete? Someone at Forrester research wrote an article in 2003 that said FCAPS was an obsolete model because it was conceived during a time when mainframes were in use. I haven't read the article but the premise of it seemed a bit overboard to me. Does the FCAPS model still hold currency among network managers/engineers today? What's FCAPS? -M
Re: Important IPv6 Policy Issue -- Your Input Requested
On 8 Nov 2004, at 22:53, Daniel Senie wrote: Is it SO hard for people to understand that it's possible today to use private address space and public address space in a network WITHOUT using NAT? I think the hard thing to understand is why you would bother using 1918 space if you didn't have to. In today's networks, printers do NOT need global addresses. If they did have globally-unique addresses, I bet they would still work just fine, though. Joe
RE: Important IPv6 Policy Issue -- Your Input Requested
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 09, 2004 12:14 AM To: Daniel Senie Cc: Randy Bush; kent crispin; [EMAIL PROTECTED] Subject: Re: Important IPv6 Policy Issue -- Your Input Requested On 8 Nov 2004, at 22:53, Daniel Senie wrote: Is it SO hard for people to understand that it's possible today to use private address space and public address space in a network WITHOUT using NAT? I think the hard thing to understand is why you would bother using 1918 space if you didn't have to. Yes. In today's networks, printers do NOT need global addresses. If they did have globally-unique addresses, I bet they would still work just fine, though. They would of course. I'm not sure why the proposal wouldn't block off some space to cover unforseen circumstances and leave it at that. IIRC, 1918 came into existence because of clashes with stock SunOS and Solaris and growth of the internet - for the most part. Much like the need for example.com to be maintained by IANA so publications can have their domain.tld examples. I agree with Leo about fees and RIR responsibility though. There's no reason *not to maintain the space in a reasonable fashion and that costs money. When money is spent, justifications are required. I have no problem justifying use of endless space regardless of the end. ;) I understand why people want to make it free. The reality is that it won't work that way again. Let's not even go down the free the network path. I fear another RMS song. YMMV. -M
RE: Important IPv6 Policy Issue -- Your Input Requested
I'm not sure why the proposal wouldn't block off some space to cover unforseen circumstances and leave it at that. uh, 7/8 of the ipv6 space is currently blocked off for unforseen circumstances. like a place to move after we have made as much of a bleedin' mess of fp=001 as we have of ipv4 space. randy
RE: Status of FCAPS model? Useful? Obsolete?
From: Hannigan, Martin [EMAIL PROTECTED] Date: Mon, 8 Nov 2004 23:54:39 -0500 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 8:52 PM [...snip...] Does the FCAPS model still hold currency among network managers/engineers today? What's FCAPS? FCAPS is the (supposedly) ISO model for network management (See wiki def at http://www.free-definition.com/FCAPS.html). It is an acronym for Fault, Configuration, Accounting, Performance, and Security... Other misc definitions: http://www.nwfusion.com/details/6184.html http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci752173,00.html http://www.iec.org/online/tutorials/ems/topic03.html However, Forrester Research seems to think that FCAPS is obsolete (at a cost of $99 to read other than the first sentence) unless you are a registered Forrester client (I am not). http://www.forrester.com/Research/LegacyIT/Excerpt/0,7208,29439,00.html Other references do not deem it dead just yet. Regards, Gregory Hicks -M - Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: [EMAIL PROTECTED] I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
RE: Status of FCAPS model? Useful? Obsolete?
On Mon, 8 Nov 2004, Hannigan, Martin wrote: Does the FCAPS model still hold currency among network managers/engineers today? What's FCAPS? I suppose that answers the question whether FCAPS holds currency among network managers/engineers. It is an ITU-T developed network management model composed of Fault, Configuration, Accounting, Performance, Security (FCAPS). Some people think it is a mandatory specification for how to manage a network; other people think it is an antiquated view of telecom network management; and yet other people think it is as relevant as the ISO 7-layer network model.
Re: Important IPv6 Policy Issue -- Your Input Requested
On Mon, 2004-11-08 at 14:53 -0500, Leo Bicknell wrote: In a message written on Mon, Nov 08, 2004 at 02:36:21PM -0500, Joe Abley wrote: Just out of interest, why do you think 1918-style space for v6 is needed? I think people have found many good uses for IPv4 1918 space, and that it is likely they would want to migrate those applications as directly as possible to IPv6. Since supporting that sort of migration does not require a huge amount of address space or burden on the addressing processes, I see no reason not to have 1918 space in IPv6. However, both of these proposals go well beyond how 1918 space works today, and both make promises of global uniqueness that are at best inappropriate, at worst a road to disaster. Please read: http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt That contains most of the answers to your questions ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
