Re: DNS .US outage
On Wed, 6 Jul 2005, Rodney Joffe wrote: On 7/6/05 10:00 PM, Church, Chuck [EMAIL PROTECTED] wrote: Thanks. Didn't have any *NIX boxes laying around to 'dig' any deeper. When I checked networksolutions' whois for neosystems.us and state.ny.us , both returned: We are unable to process your request at this time. Please try again later. Figured something was up. You meant this in passing only, right? You clearly did not intend to correlate an issue with .us DNS with whois data for .us, right? also, with the helping-out of PCH and neustar I believe these TLD boxen are actually anycast around quite some bit... though I could be mistaken about that since the hotel in boston (ATT) sees the same path as the office in ashburn (UUNET) ...
Re: OMB: IPv6 by June 2008
On Jul 6, 2005, at 10:16 PM, Alexei Roudnev wrote: IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?), Well, to date, provider based addressing works (although there were times when it was a close thing). Your alternative? security is terrible (who designed IPSec protocol?) and so so on. I wouldn't say terrible. Annoying, perhaps, but security is often like that. Your alternative? Unfortunately, it can fail only if something else will be created, which do not looks so. The something else already exists, although many are unhappy about it. It has evolved a bit -- it's now called NUTSS (http:// nutss.gforge.cis.cornell.edu/)... :-) Rgds, -drc
RE: DNS .US outage
On Wed, 2005-07-06 at 19:19 -1000, Randy Bush wrote: Thanks. Didn't have any *NIX boxes laying around to 'dig' any deeper. i believe even windoze has dig at the command line, though i don't know in what directory it lies. The web directory: http://www.isc.org/index.pl?/sw/bind/bind9.php or the ftp directory: ftp://ftp.isc.org/isc/bind/contrib/ntbind-9.3.1/BIND9.3.1.zip What is also very useful are the following two websites, so people can click around a bit and get nice pictures making everything crystalclear for them: DNSDoctor (which even supports IPv6 :) http://demo.dnsdoctor.org/ And of course DNS report: http://www.dnsreport.com/ Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: ATM
philip, did you get any useful information? nanog-l is quite good at telling you how they would redesign your network, as opposed to actually answering your question. contact offlist if you still need atm help. /bmj
RE: DNS .US outage
At 7:19 PM -1000 2005-07-06, Randy Bush wrote: Thanks. Didn't have any *NIX boxes laying around to 'dig' any deeper. i believe even windoze has dig at the command line, though i don't know in what directory it lies. That's assuming you have installed BIND for Windows, which most people probably have not done. They do have ping, nslookup, and a few other command-line tools, but then very few people using Windows seem to know how to use the command-line, or even know how to start it up. Good guess, though. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
London incidents
A number of explosion incidents have happened in London affecting the tube causing website and mobile phone saturation and some localised issues with the PSTN. From here we are able to route calls ok and networks seems a little busier, The BBC and Sky TV websites are very busy. Regards, Neil.
Re: London incidents
At 11:13 AM +0100 2005-07-07, Neil J. McRae wrote: A number of explosion incidents have happened in London affecting the tube causing website and mobile phone saturation and some localised issues with the PSTN. From here we are able to route calls ok and networks seems a little busier, The BBC and Sky TV websites are very busy. From http://news.bbc.co.uk/1/low/uk/4659093.stm: Thursday, 7 July, 2005, 10:03 GMT 11:03 UK Multiple blasts paralyse London Several people have been injured after explosions on the Underground network and a double-decker bus in London. A police spokesman said there were quite a large number of casualties at Aldgate Tube Station. And Scotland Yard confirmed one of several reports of explosions on buses in the city - in Tavistock Place - but said the cause was not yet known. UK Home Secretary Charles Clarke said several explosions in central London had caused terrible injuries. The health services are in support to deal with the terrible injuries that there have been, Clarke told reporters outside Downing Street. Number 10 said it was still unsure whether the explosions were a terrorist attack and although casualties were reported, no further details were yet available. [...] British Transport Police said incidents took place at Aldgate, Edgware Road, King's Cross, Old Street and Russell Square stations. Scotland Yard confirmed they were assisting with a major incident and said there were casualties. Hospitals have said they are no longer accepting non-emergency cases, BBC Five Live reported. The National Grid, which supplies power to the Underground, said there had been no problems with its system which could have contributed to the incidents. [ ... ] The Underground Tube system is completely closed, the buses are not running, all public transport is shut down. Police spokespeople have requested that citizens do not call the Emergency Services number unless there is an immediate life-threatening situation, and that if you are not hurt, you should stay wherever you are, stay safe, and do not travel. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
RE: London incidents
Mobile networks have been switched in to emergency services only owing to congestion and concern that devices may be activated by mobile. However the cause of some of the these incidents is still not clear.
Re: OMB: IPv6 by June 2008
On 7-jul-2005, at 7:16, Alexei Roudnev wrote: IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?) Address allocation is unsustainable but that's not IPv6's fault: it's done the same way (or even worse) in IPv4. But somehow the industry as a whole seems incapable of recognizing that having each and every ISP with 200 customers (not even that in AfriNIC/LACNIC regions), no matter how regional/local, occupy a place at the top of the global addressing hierarchy is a flawed idea. security is terrible (who designed IPSec protocol?) and so so on. Security is terrible by virtue of its nature, which explains why most people prefer to be insecure most of the time. IPsec isn't bad, although I hate the overhead (although that's childs play compared to the epidemic of quoting previous messages verbatim that is now spreading among people who should know better) and the fact that it operates on addresses makes it hard to use as a replacement for SSL. (If you think IPsec is bad, try to implement an application on top of SSL.)
Users don't fix their computers
Although many users have changed their online habits, they haven't necessarily fixed their machines, even as infected computers slow, often to a crawl. Twenty percent of users who had computer problems did not attempt a fix. Among those who did, 29 percent waited a month or longer. Two in five who tried to fix their machines did so on their own while others needed help from a friend, family member or a professional repair shop. In 20 percent of cases, the problem couldn't be fixed. http://www.washingtonpost.com/wp-dyn/content/article/2005/07/06/AR2005070601578_2.html
RE: DNS .US outage
Thanks for your help, guys. Didn't know dig existed for windows. Several ISPs (charter.net, alter.net) are choking on .us queries right now, but ATT's name server is working ok for me. Here's one failing on .us, but .com works fine: C:\temp\dnstoolsdig @24.197.96.16 com NS ; DiG 9.3.1 @24.197.96.16 com NS ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1940 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;com. IN NS ;; ANSWER SECTION: com.172800 IN NS d.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. ;; Query time: 4046 msec ;; SERVER: 24.197.96.16#53(24.197.96.16) ;; WHEN: Thu Jul 07 08:20:35 2005 ;; MSG SIZE rcvd: 245 C:\temp\dnstoolsdig @24.197.96.16 us NS ; DiG 9.3.1 @24.197.96.16 us NS ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 1682 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;us.IN NS ;; Query time: 31 msec ;; SERVER: 24.197.96.16#53(24.197.96.16) ;; WHEN: Thu Jul 07 08:20:50 2005 ;; MSG SIZE rcvd: 20 Is it possible that one of the authoritative servers for .us is unreachable/down at the moment, at least from name server 24.197.96.16's point of view? 198.6.1.2 gives similar results. Thanks again, Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design Implementation 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x4371A48D -Original Message- From: Jeroen Massar [mailto:[EMAIL PROTECTED] Sent: Thursday, July 07, 2005 4:10 AM To: Randy Bush Cc: Church, Chuck; nanog@merit.edu Subject: RE: DNS .US outage On Wed, 2005-07-06 at 19:19 -1000, Randy Bush wrote: Thanks. Didn't have any *NIX boxes laying around to 'dig' any deeper. i believe even windoze has dig at the command line, though i don't know in what directory it lies. The web directory: http://www.isc.org/index.pl?/sw/bind/bind9.php or the ftp directory: ftp://ftp.isc.org/isc/bind/contrib/ntbind-9.3.1/BIND9.3.1.zip What is also very useful are the following two websites, so people can click around a bit and get nice pictures making everything crystalclear for them: DNSDoctor (which even supports IPv6 :) http://demo.dnsdoctor.org/ And of course DNS report: http://www.dnsreport.com/ Greets, Jeroen
Re: OMB: IPv6 by June 2008
Iljitsch van Beijnum wrote: On 7-jul-2005, at 7:16, Alexei Roudnev wrote: IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?) Address allocation is unsustainable but that's not IPv6's fault: it's done the same way (or even worse) in IPv4. But somehow the industry as a whole seems incapable of recognizing that having each and every ISP with 200 customers (not even that in AfriNIC/LACNIC regions), no matter how regional/local, occupy a place at the top of the global addressing hierarchy is a flawed idea. Err... So you want to protect the incumbent ISP's? Even those once started off with 200 customers. Who is going to decide if some (today) small ISP is worthy of receiving its own PA space or not? Do they have to renumber if they manage to get more than 200 customers? Who is going to pay for the renumbering? Do they have a budget to renumber (they are small, remember)? You just looking at the status quo, but not on a timeframe of a couple of years. In a static world your reasoning would work but the world is not static. -- Andre
Re: DNS .US outage
On Thu, Jul 07, 2005 at 07:25:20AM -0500, Church, Chuck [EMAIL PROTECTED] wrote a message of 109 lines which said: Is it possible that one of the authoritative servers for .us is unreachable/down at the moment, at least from name server 24.197.96.16's point of view? It is perfectly possible. Unfortunately, all three nameservers of .us are behind the same AS and, unfortunately, they are all in the same /16. Checking the filters is a first step. PS: tracert exists on MS-Windows and c.gtld.biz replies to it.
Re: OMB: IPv6 by June 2008
Iljitsch van Beijnum [EMAIL PROTECTED] writes: You are approaching the problem at the wrong end by asking what's in it for me to adopt IPv6 now. The real question is is IPv6 inevitable in the long run. Death is inevitable in the long run, but end it all today is probably not the proper answer. ---Rob
RE: DNS .US outage
On Thu, 7 Jul 2005, Church, Chuck wrote: Thanks for your help, guys. Didn't know dig existed for windows. Several ISPs (charter.net, alter.net) are choking on .us queries right the alter.net cache's you are using arent' guaranteed to work... especially for non-customers :) but... in general they do work, sometimes slowly as all manner of people use them regardless of their 'customer' status to alternet :( Is it possible that one of the authoritative servers for .us is unreachable/down at the moment, at least from name server 24.197.96.16's point of view? 198.6.1.2 gives similar results. I'm not seeing these problems though (though that problem might have been transient too) ; DiG 8.4 us ns @cache02.ns.uu.net ; (1 server found) ;; res options: init recurs defnam dnsrch no-nibble2 ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 9205 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; QUERY SECTION: ;; us, type = NS, class = IN ;; ANSWER SECTION: us. 6D IN NSc.gtld.biz. us. 6D IN NSa.gtld.biz. us. 6D IN NSb.gtld.biz. ;; ADDITIONAL SECTION: a.gtld.biz. 5d20h12m3s IN A 209.173.53.162 b.gtld.biz. 5d20h12m3s IN A 209.173.57.162 c.gtld.biz. 5d20h12m3s IN A 209.173.60.65 ;; Total query time: 144 msec
Re: DNS .US outage
On Wed, Jul 06, 2005 at 11:27:39PM -0500, Church, Chuck wrote: Anyone else having issues with .US right now (~12AM EST)? NSlookup, etc show various .us destinations as unknown domains... Not for my site, at least: ; DiG 9.2.1 +trace microsys.us ;; global options: printcmd . 323510 IN NS F.ROOT-SERVERS.NET. . 323510 IN NS G.ROOT-SERVERS.NET. . 323510 IN NS H.ROOT-SERVERS.NET. . 323510 IN NS I.ROOT-SERVERS.NET. . 323510 IN NS J.ROOT-SERVERS.NET. . 323510 IN NS K.ROOT-SERVERS.NET. . 323510 IN NS L.ROOT-SERVERS.NET. . 323510 IN NS M.ROOT-SERVERS.NET. . 323510 IN NS A.ROOT-SERVERS.NET. . 323510 IN NS B.ROOT-SERVERS.NET. . 323510 IN NS C.ROOT-SERVERS.NET. . 323510 IN NS D.ROOT-SERVERS.NET. . 323510 IN NS E.ROOT-SERVERS.NET. ;; Received 244 bytes from 127.0.0.1#53(127.0.0.1) in 33 ms us. 172800 IN NS A.GTLD.BIZ. us. 172800 IN NS B.GTLD.BIZ. us. 172800 IN NS C.GTLD.BIZ. ;; Received 133 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 87 ms microsys.us.7200IN NS NS2.DOMAINDISCOVER.COM. microsys.us.7200IN NS NS1.DOMAINDISCOVER.COM. ;; Received 83 bytes from 209.173.53.162#53(A.GTLD.BIZ) in 40 ms microsys.us.28800 IN SOA ns1.domaindiscover.com. hostmaster.tierra.net. 3723050 86400 1800 604800 28800 ;; Received 108 bytes from 216.104.163.3#53(NS2.DOMAINDISCOVER.COM) in 98 ms 'dig +trace', incidentally, for those of you who haven't tripped over it yet, is *very* cool. I'm trying to figure out a way to shoehorn the output into something I can Nagios... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: DNS .US outage
On Thu, Jul 07, 2005 at 10:10:03AM +0200, Jeroen Massar wrote: DNSDoctor (which even supports IPv6 :) http://demo.dnsdoctor.org/ avoid loosing all connectivity sigh Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: OMB: IPv6 by June 2008
On 7 Jul 2005, at 08:27, Andre Oppermann wrote: Err... So you want to protect the incumbent ISP's? Even those once started off with 200 customers. Who is going to decide if some (today) small ISP is worthy of receiving its own PA space or not? Pretty much any ISP is capable of obtaining their own PA space under current RIR policies, regardless of size. The prohibition on PA space is to end sites, not ISPs. See, for example: http://www.arin.net/policy/index.html#six511 The myth that only large, established ISPs are able to obtain PA IPv6 address space really needs to disappear. Joe
mh (RE: OMB: IPv6 by June 2008)
Anyone here care to share operator perspectives shim6 and the like? Do we actually have anything that anyone considers workable (not whether somebody can make it happen, but viable in a commercial environment) for mh? The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: OMB: IPv6 by June 2008
Alexi, Ah, You mean the excellent 'The Mythical Man-Month' Fred Brooks wrote a second edition a few years back. I had not thought of IPv6 in terms of the second system effect but you are absolutely correct in your appraisal. Scott C. McGrath On Wed, 6 Jul 2005, Alexei Roudnev wrote: IPv6 is an excellent example of _second system_ (do you remember book, written by Brooks many years ago?) Happu engineers put all their crazy ideas together into the second version of first 9succesfull) thing, and they wonder why it do not work properly. OS/360 is one example, IPv6 will be another. IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?), security is terrible (who designed IPSec protocol?) and so so on. Unfortunately, it can fail only if something else will be created, which do not looks so. - Original Message - From: Daniel Golding [EMAIL PROTECTED] To: Scott McGrath [EMAIL PROTECTED]; David Conrad [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Wednesday, July 06, 2005 8:58 AM Subject: Re: OMB: IPv6 by June 2008 There is an element of fear-mongering in this discussion - that's why many of us react poorly to the idea of IPv6. How so? - We are running out of IPv4 space! - We are falling behind #insert scary group to reinforce fear of Other! - We are not on the technical cutting edge! Fear is a convenient motivator when facts are lacking. I've read the above three reasons, all of which are provable incorrect or simple fear mongering, repeatedly. The assertions that we are falling behind the Chinese or Japanese are weak echoes of past fears. The market is our friend. Attempts to claim that technology trumps the market end badly - anyone remember 2001? The market sees little value in v6 right now. The market likes NAT and multihoming, even if many of us don't. Attempts to regulate IPv6 into use are as foolish as the use of fear-based marketing. The gain is simply not worth the investment required. - Daniel Golding On 7/6/05 11:41 AM, Scott McGrath [EMAIL PROTECTED] wrote: You do make some good points as IPv6 does not address routing scalability or multi-homing which would indeed make a contribution to lower OPEX and be easier to 'sell' to the financial people. As I read the spec it makes multi-homing more difficult since you are expected to receive space only from your SP there will be no 'portable assignments' as we know them today. If my reading of the spec is incorrect someone please point me in the right direction. IPv6's hex based nature is really a joy to work with IPv6 definitely fails the human factors part of the equation. Scott C. McGrath On Wed, 6 Jul 2005, David Conrad wrote: On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote: IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed. IPv6 would have been adopted much sooner if it had solved a problem that caused significant numbers of end users or large scale ISPs real pain. If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering all the hand wringing about how the Asians and Europeans are going to overtake the US would not occur. Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you like, blame it on the accountants... Rgds, -drc -- Daniel Golding Network and Telecommunications Strategies Burton Group
Re: OMB: IPv6 by June 2008
Joe Abley wrote: On 7 Jul 2005, at 08:27, Andre Oppermann wrote: Err... So you want to protect the incumbent ISP's? Even those once started off with 200 customers. Who is going to decide if some (today) small ISP is worthy of receiving its own PA space or not? Pretty much any ISP is capable of obtaining their own PA space under current RIR policies, regardless of size. The prohibition on PA space is to end sites, not ISPs. I know but I was responding to Iljitsch who told us: # Address allocation is unsustainable but that's not IPv6's fault: it's done the same way # (or even worse) in IPv4. But somehow the industry as a whole seems incapable of # recognizing that having each and every ISP with 200 customers (not even that in # AfriNIC/LACNIC regions), no matter how regional/local, occupy a place at the top of the # global addressing hierarchy is a flawed idea. The myth that only large, established ISPs are able to obtain PA IPv6 address space really needs to disappear. It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable. -- Andre
Re: OMB: IPv6 by June 2008
My day to day is primarily supporting high-performance research computing on the network side if I can add new functionality without incurring accquisition costs or operational expenses AND not changing experimental regimes in my area of responsibility that is a BIG win and one that 'slides past the accountants'. As it stands now IPv6 functionality requires that the researchers replace their network connected instruments many of which are purpose built. Some of the instruments are old (but network attached) and are used in long term experiments and instrument replacement would invalidate the results. A interoperable IPv6 would have been adopted quickly in my environment especially since it could have been added along with routine scheduled network element software maintenance. With the current IPv6 implementation I have to 1 - Get new (non-multihomed) address space from each of our upstreams 2 - Replace network elements with IPv6 compatible network elements and S/W 3 - Convince all the researchers to dump all their instruments and buy new ones 4 - Retrain entire staff to support IPv6 No matter how hard I try I just am not going to be able to make any cogent argument which will allow the implementation of IPv6 since it appears to offer no benefits to the user community which in my case is extremely well informed on technologies which will benefit their research. The best I can hope for is IPv4 to IPv6 gateways. Scott C. McGrath On Wed, 6 Jul 2005, Edward Lewis wrote: At 10:57 -0400 7/6/05, Scott McGrath wrote: IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed. Sliding anything past the accountants is bad practice. Is the goal to run IPv6 or to run a communications medium to support society? If it costs $1M to adopt IPv6 in the next quarter, what would you take the $1M from? (I used to work at a science research center. Having a good network wasn't the goal, doing science was. Without good science, there would be no FY++ budget for a better network.) The Internet serves society, society owes nothing to the Internet. Members of this list may prioritize communications technology, other members of society may prioritize different interests and concerns. That is why IPv6 must offer a benefit greater than it's cost. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: mh (RE: OMB: IPv6 by June 2008)
On 2005-07-07, at 10:10, Kuhtz, Christian wrote: Anyone here care to share operator perspectives shim6 and the like? Do we actually have anything that anyone considers workable (not whether somebody can make it happen, but viable in a commercial environment) for mh? There is no operational or implementation experience with shim6 at this time, that I know of (the technical specifications for shim6 are currently incomplete). The shim6 working group has its first meeting in August in Paris, after which the goal is to progress quickly to a set of specifications which can be implemented. As an easy-to-read overview of the shim6 approach, the following rough draft may be useful: http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt Joe
RE: London incidents
Our thoughts and prayers are with everyone in London. with regard to telecommunications services, Tim Richardson writes in The Register: [snip] Phone networks have been jammed today following a series of blasts that hit London's public transport network this morning. Mobile networks in particular have been put under pressure as people use their phones to contact friends and family following the explosions. In a statement Vodafone said: Understandably we are experiencing significant network congestion but we are working closely with the emergency services. In these circumstances, we would ask all of our customers in Central London to avoid making unnecessary or lengthy phone calls. BT has also reported that its network is intact although it is witnessing a massive spike in calls. [snip] http://www.theregister.co.uk/2005/07/07/london_phone/ - ferg -- Neil J. McRae [EMAIL PROTECTED] wrote: Mobile networks have been switched in to emergency services only owing to congestion and concern that devices may be activated by mobile. However the cause of some of the these incidents is still not clear. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: OMB: IPv6 by June 2008
On 2005-07-07, at 10:23, Andre Oppermann wrote: It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable. With the hole-punching/CIDR abuse multihoming that is widely used in IPv4, a slot in the DFZ gets burned each time an end site adds a provider, regardless of whether they are using PA or PI addresses. This slot represents state information for the multi-homed site which answers the question how else can this set of addresses be reached? The shim6 approach shifts this state from the DFZ to the endpoints which are exchanging unicast traffic. The endpoints exchange a set of possible locators through a protocol element within the IP layer and handle locator migration transparently to the transport layer above. Hence the question how else can this particular remote address be reached is answered using information on the host, not information in the network. With shim6 an end site can multi-home using one PA prefix per provider, without taking up additional slots in the DFZ. Hosts within the site are given multiple addresses (locators), and the layer-3 shim handles any change of locator needed for traffic exchanged between any two hosts. If one (or both) of the hosts exchanging traffic don't support shim6, then the traffic is exchanged without transport-layer stability across re-homing events (and, potentially, without any optimisation as to the choice of endpoint addresses for the session). So, the shim6 future of multihoming looks like this: 1. ISPs multi-home exactly as people are used to doing today, using PI prefixes, and taking up a slot in the DFZ per transit provider. Everybody is familiar with this already. There is no change for ISPs in this picture. 2. Multi-homed end sites obtain one PA prefix per upstream ISP, and hosts within those end-sites are assigned multiple addresses (in some automated, secure and controllable fashion). There are no additional slots burned in the DFZ by end site multi-homing. Hosts obtain transport-layer reliability across re-homing events using shim6, rather than relying on the network to take care of it. Joe
Re: OMB: IPv6 by June 2008
On 7-jul-2005, at 16:23, Andre Oppermann wrote: Err... So you want to protect the incumbent ISP's? No, it should always be possible to start new ISPs. Even those once started off with 200 customers. Who is going to decide if some (today) small ISP is worthy of receiving its own PA space or not? Pretty much any ISP is capable of obtaining their own PA space under current RIR policies, regardless of size. In ARIN, RIPE and APNIC regions you need to plan to give out address pace to 200 customers within a few years. So only ISPs who are small now and are pessimistic about their future growth don't qualify. The myth that only large, established ISPs are able to obtain PA IPv6 address space really needs to disappear. It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable. If the routing table is large, making the protocols that create the routing table better won't help you. The problem is that today, everyone occupies a slot at the top of the global hierarchy. I'm not saying people shouldn't occupy slots, I'm saying they don't have to be at the top of the global hierarchy.
Re: OMB: IPv6 by June 2008
On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote: 1 - Get new (non-multihomed) address space from each of our upstreams You mean from Abilene or get your own PA space? What is so odd about this, a number of other universities* already did this. Oh and for people in the ARIN region getting it is gratuit for the time being when you already have IPv4 space. * = see the list at http://www.sixxs.net/tools/grh/dfp/all/ 2 - Replace network elements with IPv6 compatible network elements and S/W On a per-link basis, start with tunnels where needed, go native later on or rather directly when possible. Most Cisco's can be upgraded to support IPv6, JunOS supports it too, though they now suddenly require some absurd fee especially for IPv6. For most layer2 setups getting IPv6 working is really a matter of upgrading the kernels or just enabling it. 3 - Convince all the researchers to dump all their instruments and buy new ones Why? They can gradually upgrade when time and need arises. There is no flagday on which IPv4 disappears and IPv6 suddenly takes everything over. Also nobody is forcing you to, but it might be smart to do it while you have time and not when somebody demands it from you to do it yesterday ;) 4 - Retrain entire staff to support IPv6 You have to train people to drive a car, to program a new VCR etc. What is so odd about this? No matter how hard I try I just am not going to be able to make any cogent argument which will allow the implementation of IPv6 since it appears to offer no benefits to the user community which in my case is extremely well informed on technologies which will benefit their research. Maybe not at this time but it will later. Harvard is of course also one of the lucky fews having a /8 at their disposal for playing around. The best I can hope for is IPv4 to IPv6 gateways. Which exist, eg http://ipv6gate.sixxs.net ;) And you can also make them yourself easily of course. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Cisco hires FCC's Pepper
Not related to operational issues (or is it?), but there;s a story in this morning's Advanced Ip Pipeline about Cisco hiring ormer FCC staffer Robert Pepper: [snip] With a title of senior managing director, global advanced technology policy, Pepper will be working under Laura Ipsen, Cisco's vice president of worldwide government affairs. Pepper said his role will be similar to the one he performed at the FCC -- mainly, educating policymakers about new technologies and their potential impact on economic growth. It'll be the same kind of education I helped bring to the chairmen [of the FCC], Pepper said. I'll help people look at the cool new things, and try to understand what are the [policy] implications. [snip] http://www.advancedippipeline.com/165700366 I just thought that bit if news was very interesting. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: OMB: IPv6 by June 2008
Jeroen Massar wrote: On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote: 4 - Retrain entire staff to support IPv6 You have to train people to drive a car, to program a new VCR etc. What is so odd about this? I had training to drive a car once in my life when I got my drivers license. I don't have to get a fresh training for every new car I end up driving throughout my life. If I need training to program my new VCR then the operating mode of that VCR is broken and I'm going to return it asap. It's that simple. Why are people buying iPod's like crazy? Because these thingies don't require training. People intuitively can use them because the GUI is designed well. -- Andre
Re: OMB: IPv6 by June 2008
Joe Abley wrote: On 2005-07-07, at 10:23, Andre Oppermann wrote: It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable. With the hole-punching/CIDR abuse multihoming that is widely used in IPv4, a slot in the DFZ gets burned each time an end site adds a provider, regardless of whether they are using PA or PI addresses. This slot represents state information for the multi-homed site which answers the question how else can this set of addresses be reached? The shim6 approach shifts this state from the DFZ to the endpoints which are exchanging unicast traffic. The endpoints exchange a set of possible locators through a protocol element within the IP layer and handle locator migration transparently to the transport layer above. Hence the question how else can this particular remote address be reached is answered using information on the host, not information in the network. With shim6 an end site can multi-home using one PA prefix per provider, without taking up additional slots in the DFZ. Hosts within the site are given multiple addresses (locators), and the layer-3 shim handles any change of locator needed for traffic exchanged between any two hosts. If one (or both) of the hosts exchanging traffic don't support shim6, then the traffic is exchanged without transport-layer stability across re-homing events (and, potentially, without any optimisation as to the choice of endpoint addresses for the session). So, the shim6 future of multihoming looks like this: 1. ISPs multi-home exactly as people are used to doing today, using PI prefixes, and taking up a slot in the DFZ per transit provider. Everybody is familiar with this already. There is no change for ISPs in this picture. 2. Multi-homed end sites obtain one PA prefix per upstream ISP, and hosts within those end-sites are assigned multiple addresses (in some automated, secure and controllable fashion). There are no additional slots burned in the DFZ by end site multi-homing. Hosts obtain transport-layer reliability across re-homing events using shim6, rather than relying on the network to take care of it. Ok, you don't think this thing will ever fly, do you? -- Andre
Re: OMB: IPv6 by June 2008
On Thu, 2005-07-07 at 18:02 +0200, Andre Oppermann wrote: Jeroen Massar wrote: On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote: 4 - Retrain entire staff to support IPv6 You have to train people to drive a car, to program a new VCR etc. What is so odd about this? I had training to drive a car once in my life when I got my drivers license. I don't have to get a fresh training for every new car I end up driving throughout my life. You will have to get an additional license for driving a truck or even when you are getting a caravan behind that car of yours though. Motorbikes also have different licenses and you get separate trainings for those. They all have wheels, look the same, operate somewhat the same, but are just a little bit different and need a bit different education. You also either read something, educated yourself or even got a training to operate IPv4 networks, now you will just need a refresh for IPv6. You can opt to not take it, but then don't complain you don't understand it. For that matter if you don't understand IPv6 you most likely don't IPv4 (fully) either. If I need training to program my new VCR then the operating mode of that VCR is broken and I'm going to return it asap. Then a lot of VCR's will be returned because if there is one thing many people don't seem to understand, even after reading the manual then it is a VCR. It's that simple. Why are people buying iPod's like crazy? Because these thingies don't require training. People intuitively can use them because the GUI is designed well. So you didn't read the manual of or train yourself to use your compiler| bgp|isis|rip|operatingsystem| and a lot of other things ? IP networks are not meant for the general public, they only care that the apps that use it work, they don't type on routers. Protocols don't have GUI's or do you have a point and click BGP? :) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: OMB: IPv6 by June 2008
we're off on the usual strange tangents. next will be whether it is ethical to walk in your neighbor's open house if they're running ipv6:-). ipv4 has some problems. the world has hacked around the major ones with things such as [holding nose] nat. the ivtf came up with a technically weak second system syndrome patch which has yet to show enough sizzle to sell against the hacks to ipv4. so the ivtf, a decade out, is trying to hack to make it work. a shim on top of second system syndrome. i am not holding my my breath. market physics will say whether scaling issues with nat et al. are sufficiently obnoxious to cause ipv6 to become sufficiently attractive; no amount of conjecturbation tm here will change that. if it becomes enabling and profitable, then folk will deploy and move. if not, they won't. life is simple. in the meantime, some pretty sharp old dawgs at the nsf food dish want to make a try for a next-gen vision. time will tell if they can come up with real fundamental change, or just third system syndrome. if i could predict this one, i would bet on the horses, not program computers. in the mean time, and these are mean times, we need to move the customers' packets. i definitely keep my eye on these futures, but maybe not too much of my wallet. randy
Re: OMB: IPv6 by June 2008
Andre, On Thu, Jul 07, 2005 at 06:04:22PM +0200, Andre Oppermann wrote: Joe Abley wrote: On 2005-07-07, at 10:23, Andre Oppermann wrote: It was about a spot in the global routing table. No matter if one gets PA or PI they get a routing table entry in the DFZ. There is no way around it other than to make the routing protocols more scaleable. With the hole-punching/CIDR abuse multihoming that is widely used in IPv4, a slot in the DFZ gets burned each time an end site adds a provider, regardless of whether they are using PA or PI addresses. This slot represents state information for the multi-homed site which answers the question how else can this set of addresses be reached? The shim6 approach shifts this state from the DFZ to the endpoints which are exchanging unicast traffic. The endpoints exchange a set of possible locators through a protocol element within the IP layer and handle locator migration transparently to the transport layer above. Hence the question how else can this particular remote address be reached is answered using information on the host, not information in the network. With shim6 an end site can multi-home using one PA prefix per provider, without taking up additional slots in the DFZ. Hosts within the site are given multiple addresses (locators), and the layer-3 shim handles any change of locator needed for traffic exchanged between any two hosts. If one (or both) of the hosts exchanging traffic don't support shim6, then the traffic is exchanged without transport-layer stability across re-homing events (and, potentially, without any optimisation as to the choice of endpoint addresses for the session). So, the shim6 future of multihoming looks like this: 1. ISPs multi-home exactly as people are used to doing today, using PI prefixes, and taking up a slot in the DFZ per transit provider. Everybody is familiar with this already. There is no change for ISPs in this picture. 2. Multi-homed end sites obtain one PA prefix per upstream ISP, and hosts within those end-sites are assigned multiple addresses (in some automated, secure and controllable fashion). There are no additional slots burned in the DFZ by end site multi-homing. Hosts obtain transport-layer reliability across re-homing events using shim6, rather than relying on the network to take care of it. Ok, you don't think this thing will ever fly, do you? I'm interested in what aspect(s) of shim6 you think might cause it to fail? Is it the technology itself (as much as is specified anyway), it's complexity, the underlying multihoming model, ...? Dave pgpGf42MXHTNL.pgp Description: PGP signature
Re: OMB: IPv6 by June 2008
We have relatively PI address space in IPv4, which works fine, even with current routers. No any problem to hold the whole world-wide routing with a future ones. Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005 and it will not be in 2008 - even if you will have 1,000,000 routes). IPv6 schema was build to resolve problem which do not exists anymore (with fast CPU and cheap memory and ASIC's). I mean - when people switched from IPv4 to IPv6, they changed too much and too hard, trying to implement all their ideas. Result is terrible. IPSec - compare SSH and IPSec. Compare IPSec and PPTP. No, IPSec is extremely bad thing. - Original Message - From: David Conrad [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: Daniel Golding [EMAIL PROTECTED]; Scott McGrath [EMAIL PROTECTED]; nanog@merit.edu Sent: Thursday, July 07, 2005 12:01 AM Subject: Re: OMB: IPv6 by June 2008 On Jul 6, 2005, at 10:16 PM, Alexei Roudnev wrote: IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?), Well, to date, provider based addressing works (although there were times when it was a close thing). Your alternative? security is terrible (who designed IPSec protocol?) and so so on. I wouldn't say terrible. Annoying, perhaps, but security is often like that. Your alternative? Unfortunately, it can fail only if something else will be created, which do not looks so. The something else already exists, although many are unhappy about it. It has evolved a bit -- it's now called NUTSS (http:// nutss.gforge.cis.cornell.edu/)... :-) Rgds, -drc
Re: OMB: IPv6 by June 2008
What's the problem with independent address space for every entity (company, family, enterprise) which wants it? Big routing tables? Is RT of 1,000,000 routes BIG? I do not think so. Memory is cheap, modern routing schemas like CEF are effective. How many entities do we have on earth? It was a problem, but it IS NOT ANYMORE. IPSec - see all ISAKMP schema and IPSEC security associations, and see IPSec incompatibilities. Compare with SSL (works out-of-the-box in 99.999% cases, and allows both, full and hard security with root certificates etc, or simple security based on _ok, I trust you first time, then we can work_. Why MS uses PPTP? Because it is much more practuical vs IPSec. IPv4 was strong because it was designed by practical people and not so much by commiteets., IPv6 was designed by commiteets mainly. Do you know, that 'camel is horse designed by commiteet'? - Original Message - From: Mohacsi Janos [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: Daniel Golding [EMAIL PROTECTED]; Scott McGrath [EMAIL PROTECTED]; David Conrad [EMAIL PROTECTED]; nanog@merit.edu Sent: Thursday, July 07, 2005 1:08 AM Subject: Re: OMB: IPv6 by June 2008 On Wed, 6 Jul 2005, Alexei Roudnev wrote: IPv6 is an excellent example of _second system_ (do you remember book, written by Brooks many years ago?) Happu engineers put all their crazy ideas together into the second version of first 9succesfull) thing, and they wonder why it do not work properly. OS/360 is one example, IPv6 will be another. But I think IPv6 will one day a primary system. IPv6 address allocation schema is terrible (who decided to use SP dependent spaces?), security is terrible (who designed IPSec protocol?) and so so on. If you can propose better solution to not to blow up routing table with large number of entries you can speak at IETF v6ops. What is the problem with IPSec? Unfortunately, it can fail only if something else will be created, which do not looks so. Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 - Original Message - From: Daniel Golding [EMAIL PROTECTED] To: Scott McGrath [EMAIL PROTECTED]; David Conrad [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: Wednesday, July 06, 2005 8:58 AM Subject: Re: OMB: IPv6 by June 2008 There is an element of fear-mongering in this discussion - that's why many of us react poorly to the idea of IPv6. How so? - We are running out of IPv4 space! - We are falling behind #insert scary group to reinforce fear of Other! - We are not on the technical cutting edge! Fear is a convenient motivator when facts are lacking. I've read the above three reasons, all of which are provable incorrect or simple fear mongering, repeatedly. The assertions that we are falling behind the Chinese or Japanese are weak echoes of past fears. The market is our friend. Attempts to claim that technology trumps the market end badly - anyone remember 2001? The market sees little value in v6 right now. The market likes NAT and multihoming, even if many of us don't. Attempts to regulate IPv6 into use are as foolish as the use of fear-based marketing. The gain is simply not worth the investment required. - Daniel Golding On 7/6/05 11:41 AM, Scott McGrath [EMAIL PROTECTED] wrote: You do make some good points as IPv6 does not address routing scalability or multi-homing which would indeed make a contribution to lower OPEX and be easier to 'sell' to the financial people. As I read the spec it makes multi-homing more difficult since you are expected to receive space only from your SP there will be no 'portable assignments' as we know them today. If my reading of the spec is incorrect someone please point me in the right direction. IPv6's hex based nature is really a joy to work with IPv6 definitely fails the human factors part of the equation. Scott C. McGrath On Wed, 6 Jul 2005, David Conrad wrote: On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote: IPv6 would have been adopted much sooner if the protocol had been written as an extension of IPv4 and in this case it could have slid in under the accounting departments radar since new equipment and applications would not be needed. IPv6 would have been adopted much sooner if it had solved a problem that caused significant numbers of end users or large scale ISPs real pain. If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering all the hand wringing about how the Asians and Europeans are going to overtake the US would not occur. Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you
RE: mh (RE: OMB: IPv6 by June 2008)
From: Joe Abley [mailto:[EMAIL PROTECTED] On 2005-07-07, at 10:10, Kuhtz, Christian wrote: Anyone here care to share operator perspectives shim6 and the like? Do we actually have anything that anyone considers workable (not whether somebody can make it happen, but viable in a commercial environment) for mh? There is no operational or implementation experience with shim6 at this time, that I know of (the technical specifications for shim6 are currently incomplete). The shim6 working group has its first meeting in August in Paris, after which the goal is to progress quickly to a set of specifications which can be implemented. As an easy-to-read overview of the shim6 approach, the following rough draft may be useful: http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. To me, this is still a glaring hole as it has been for years now and nobody seems to be making any fundamental progress here. Partially probably because the deck seems to be fundamentally stacked against mh, which doesn't appear to have been a design criteria in the first place. Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: London incidents
Neil J. McRae wrote: A number of explosion incidents have happened in London affecting the tube causing website and mobile phone saturation and some localised issues with the PSTN. From here we are able to route calls ok and networks seems a little busier, The BBC and Sky TV websites are very busy. When 9/11 happened people in the US were surprised about the phone systems going down and there being silence, i.e. no tone when you pick up the phone. In Israel, unfortunately, we are pretty used to such events and what follows technically. I wonder, has anyone ever prepared a best practices paper of some sort as to what can be expected in cases of big emergencies and mass hysteria, for networks? Thanks, Gadi.
FW: Request for Peering with AS4788 at Equinix SJO/ASH/LA
We are peered with Equinix Direct and Internap in San Jose and have received a couple solicitations from random companies to peer, though we're not a provider of transit. I have no desire to find new peers, so I'm not considering the offer below -- just wondering if this is a red flag that's worth passing on. I am skeptical, but I suppose this could be harmless. FWIW, I've seen AS4788 on old CIDR reports under Possible Bogus Routes: http://www.ripe.net/ripe/maillists/archives/routing-wg/2003/msg00146.htm l -Jason -- Jason Sloderbeck Positive Networks [EMAIL PROTECTED] From: Muhawira Muhamed [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 06, 2005 9:38 PM To: [EMAIL PROTECTED] Subject: Request for Peering with AS4788 at Equinix SJO/ASH/LA Dear Peering Admin, We are TMNet(AS4788) and would like to peer with you on EQUINIX/PAIX. Below are our details. ASNUM - 4788 AS Set - AS4788 Website - http://www.tm.net.my http://www.tm.net.my/ IP - (206.223.116.149) [Equinix-San Jose] IP - (206.223.123.63) [Equinix-Los Angeles] IP - (206.223.115.149) [Equinix - Ashburn] IP - (198.32.176.26) [PAIX-Palo Alto] IP - (195.66.224.47) [LINX - London] IP - (217.79.160.135) [XPE - London] IP - (210.171.224.194) [JPIX - Japan] IP - (192.145.251.44) [KINX - Korea] IP - (202.40.161.213) [HKIX - Hong Kong] IPv6 - (2001:7f8:4:0::12b4:1) [LINX - London] IPv6 - (2001:504:0:1::4788:1) [Equinix - San Jose] IPv6 - (2001:504:0:2::4788:1) [Equinix - Ashburn] Advertised prefixes (IPv4): ~ 215 Contact/Support : [EMAIL PROTECTED]/[EMAIL PROTECTED] NOC Phone : +60322404600 If you would like to set up peering with us please respond with your details and confirmation that you have set your end up and we will complete our end. If you have received this email twice then please accept our apologies. This would have been due to an outbound mail issue which meant we had to resend the email. Please let us know. Thank you. Muhawira Muhamed CORE IMPLEMENTATION DIVISION, TELEKOM MALAYSIA BERHAD (128740-P), TM Annexe, No.1 Lengkok Pantai Baru, 59200 Kuala Lumpur. Malaysia (+ 8 GMT) tel:+ 603 2240 3040 fax: + 603 2240 3234
Re: OMB: IPv6 by June 2008
On 7-jul-2005, at 18:58, Alexei Roudnev wrote: Is RT of 1,000,000 routes BIG? We've had this discussion very many times. Both the maximum number of routes routers can hold at any time in the future and the number of prefixes people are going to inject at that time are unknown. This makes it impossible to guarantee that the former is higher than the latter. Compare with SSL (works out-of-the-box in 99.999% cases, and allows both, full and hard security with root certificates etc, or simple security based on _ok, I trust you first time, then we can work_. If I'm on the same shared medium as you I can kill your SSL session with one packet. IPv4 was strong because it was designed by practical people and not so much by commiteets., IPv6 was designed by commiteets mainly. Do you know, that 'camel is horse designed by commiteet'? So when is the last time you sent an ICMP source quench? Or set any of the low delay / high reliability / high throughput bits in the IP header? - Original Message - What am I, your janitor? Can't you throw your garbage in the trashcan?
Re: OMB: IPv6 by June 2008
David Meyer wrote: On Thu, Jul 07, 2005 at 06:04:22PM +0200, Andre Oppermann wrote: Ok, you don't think this thing will ever fly, do you? I'm interested in what aspect(s) of shim6 you think might cause it to fail? Is it the technology itself (as much as is specified anyway), it's complexity, the underlying multihoming model, ...? [x] All of the reasons you stated. -- Andre
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 7, 2005, at 1:09 PM, Kuhtz, Christian wrote: As an easy-to-read overview of the shim6 approach, the following rough draft may be useful: http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. To me, this is still a glaring hole as it has been for years now and nobody seems to be making any fundamental progress here. Partially probably because the deck seems to be fundamentally stacked against mh, which doesn't appear to have been a design criteria in the first place. I've been poking around with end-host / end-network multihoming at the transport and application layers. See, e.g., MONET, a multi-homed Web proxy designed to achieve high availability: http://nms.lcs.mit.edu/ron/ronweb/ In general, this kind of end-host informed multihoming has a lot of potential for improving availability and performance (because the end-points actually see what they're getting), but at the cost of some extra implementation complexity. The shim6 mechanism (in the general sense, not speaking to the specifics of shim6 negotiation, etc.), when augmented with some end-host smarts, could be a nice way to do end-host based multihoming in the ipv6 context. -Dave
ICANN Posts New gTLD Questions Paper
..and I've hit my post limit for the day. :-) http://icann.org/announcements/announcement-06jul05.htm - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
RE: OMB: IPv6 by June 2008
we're off on the usual strange tangents. next will be whether it is ethical to walk in your neighbor's open house if they're running ipv6:-). Why of course it is. Afterall, anyone should be able to engage in any (group hug|rape) at any time of their chosing with anyone else. And if you don't lock your door, barricade it, build a moat, with automatic machine gun fire etc, well, then it's your fault that it happened to you.. isn't it. Afterall, you dressed for the part by showing up with your own 128-bit ball and chain. Except for the odd case where hugs are actually being passed out. Oh, sorry, was that too cynical? ipv4 has some problems. the world has hacked around the major ones with things such as [holding nose] nat. the ivtf came up with a technically weak second system syndrome patch which has yet to show enough sizzle to sell against the hacks to ipv4. so the ivtf, a decade out, is trying to hack to make it work. a shim on top of second system syndrome. i am not holding my my breath. Ditto. market physics will say whether scaling issues with nat et al. are sufficiently obnoxious to cause ipv6 to become sufficiently attractive; no amount of conjecturbation tm here will change that. if it becomes enabling and profitable, then folk will deploy and move. if not, they won't. life is simple. It is possible that outside NA deployment volume may change NA deployment habits. We're already not in the driver seat with several networking technologies as we previously were. Plain old economics. A 'maybe'. The real question is if and how operators should prepare for their deployments. Some of us run a bit more than a mom and pop shop and when massive infrastructures are being revamp where it would be nice if there was a clear direction where to place bets. Short of saying hey, it's all layer 2, why do I care. I guess I could always go pay a consultant for a non answer. ;-) Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: OMB: IPv6 by June 2008
On 2005-07-07, at 12:53, Alexei Roudnev wrote: We have relatively PI address space in IPv4, which works fine, even with current routers. No any problem to hold the whole world-wide routing with a future ones. Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005 and it will not be in 2008 - even if you will have 1,000,000 routes). IPv6 schema was build to resolve problem which do not exists anymore (with fast CPU and cheap memory and ASIC's). Whether or not you see DFZ state growth as a serious enough issue to architect around depends on how much additional routing complexity you see in the network's future. Maybe there's the potential for 50,000,000 routes in the DFZ if everybody who really wants to multi- home is able to do so; maybe it's higher. Regardless, there's still a point where the demand for routing slots will outstrip availability. However, DFZ state bloat is not the only potential benefit to keeping multi-homing state at the edge of the network. Here's an example, based in a future in which shim6 is successfully deployed in sufficient numbers of IP stacks that it can be considered commonplace, and consumer IPv6 internet access is easy to come by. This is a thought experiment; bear with me. I promise to shut up about shim6 after this message. I have some devices in my home which require Internet connectivity -- a handful of wireless base stations, some MP3 players, a couple of TiVO-style-things, an xbox in the basement, a few VoIP phones, a few laptops, etc. Maybe I even have the mythical Internet fridge, without which no forward-looking IPv6 thought experiment would be complete. Since I can get both DSL and cable modem service for not much money (about $20/month each) and since I get grumpy when my Internet access goes away, I decide to buy both DSL and cable modem service. The more Internet-dependent devices I have in my house, the more attractive this option is. Both Internet access services are delivered to my house in the form of small routers, which answer router solicitation messages each with EUI-64 addresses out of different PA /64s (one per provider). My various networked devices each get two addresses in this way. When they talk to some remote device that has a shim6 element in its protocol stack, I get all the benefits that I would expect to achieve by multi-homing: if one provider goes down, I use the other one without having to debug anything, or yank any cables, or answer any difficult pop-up questions. Sessions that are established before one provider dies continue to work afterwards. New sessions start up just fine. When the provider comes back on-line, everything continues to work. I probably don't even notice that the provider had a problem. My providers don't have to care that I am multi-homing. They deploy precisely the same infrastructure regardless of whether I am multi- homed or not. They don't have to talk BGP to me. They don't need a multi-homing product. I'm just a regular customer. As a consumer, I don't even have to know what multi-homing is; I just need to order two (or more) completely independent Internet access services and have the installer plug them into the switch in my basement that connects everything else together. This picture seems like it could scale to many millions of multi- homed end sites. It seems like it is eminently supportable. It seems like the kind of thing people would like to buy, if they knew they could. If you compare this shim6/IPv6 picture to one in which every single multi-homed end site needs PI addresses and to announce a unique prefix into the DFZ in order to multi-home, then you either have a system which doesn't scale or you don't have much multi-homing going on. If you compare this shim6/IPv6 picture to one in which the locator selection is done in NAT boxes instead of in the host protocol stack, then you have the additional complexity of NAT boxes communicating with each other to determine path reachability through their respective uplinks; you have coordination issues between multiple NAT boxes on an inside address ranges to us; you maybe even need some ability in hosts to switch their default routes between NAT boxes when paths through one stop working. And at the end of the day you still have NAT, with the attendant protocol kludges built into every P2P and telephony app to allow them squeeze around the middlebox minefield. Joe
RE: mh (RE: OMB: IPv6 by June 2008)
I've been poking around with end-host / end-network multihoming at the transport and application layers. See, e.g., MONET, a multi-homed Web proxy designed to achieve high availability: http://nms.lcs.mit.edu/ron/ronweb/ In general, this kind of end-host informed multihoming has a lot of potential for improving availability and performance (because the end-points actually see what they're getting), but at the cost of some extra implementation complexity. The shim6 mechanism (in the general sense, not speaking to the specifics of shim6 negotiation, etc.), when augmented with some end-host smarts, could be a nice way to do end-host based multihoming in the ipv6 context. But, isn't that just a host based approach in the end and not a solution for entire networks? And if it isn't for entire networks, why do I need any to any connectivity anyway? I know, there's nothing that prevents it (or any schema like it, including shim6) from being network to network, but, good grief, what a huge amount of overhead to design around a requirements flaw. This sort of Moebius strip logic that's used to explain/solve the problem which has been created is fun to watch, but really just sucks in the end. One could argue, however, that we don't need multihoming, we all need to pour money into CDNs for things we really care about and lets somebody else do the worrying. . And it all seems like such a hack. Hurray, network based services are back. The PSTN is dead, long live the PSTN. Argh. Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
RE: OMB: IPv6 by June 2008
Compare with SSL (works out-of-the-box in 99.999% cases, and allows both, full and hard security with root certificates etc, or simple security based on _ok, I trust you first time, then we can work_. If I'm on the same shared medium as you I can kill your SSL session with one packet. Only if shared medium = vanilla CSMA/CD Ethernet or the like. Just because 'transport' is shared, doesn't mean you as the consumer of information carried by the network have visibility. * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 118
Re: OMB: IPv6 by June 2008
Alexei, On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. How many entities do we have on earth? Well, there are 6 billion people on the planet. Don't know how many companies or families. Don't know how many autonomous devices there will be (e.g., cars, planes, boats, ships, satellites, light bulbs, gastro-intestinal probes, etc. etc.). It was a problem, but it IS NOT ANYMORE. You're not thinking big enough. IPSec - see all ISAKMP schema and IPSEC security associations, and see IPSec incompatibilities. Any new protocol has initial interoperability problems when it is being developed by different people/teams. Compare with SSL (works out-of-the-box in 99.999% cases, and allows both, full and hard security with root certificates etc, or simple security based on _ok, I trust you first time, then we can work_. a) I suspect most SSL implementations derive out of the same code base. b) SSL has been around longer. c) SSLeay had lots of interoperability issues when it first came out. Why MS uses PPTP? Because it is much more practuical vs IPSec. MS uses PPTP because it meets their business requirements. The fact that it is more practical is a second order effect. Rgds, -drc
Re: OMB: IPv6 by June 2008
On Thu, Jul 07, 2005 at 09:58:56AM -0700, Alexei Roudnev wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? Big routing tables? Is RT of 1,000,000 routes BIG? I do not think so. Memory is cheap, modern routing schemas like CEF are effective. How many entities do we have on earth? It was a problem, but it IS NOT ANYMORE. One of the problems that is frequently overlooked here is that while the size of the DFZ is more or less bounded (although not as meaningfully so for IPv6 as it is for IPv4), the dynamic nature of the routing table is not bounded. Add to this that the less aggregation you have, the more the DFZ is exposed to those dynamics. The point here being that the memory requirements of the DFZ table is just one of the dimensions that must be considered if we intend the network to scale. Dave pgpqDJUAJZDNI.pgp Description: PGP signature
RE: OMB: IPv6 by June 2008
Alexei, On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. I would contend that is not true. What says that every device inside a company, family, enterprise etc has to be available and reachable by anyone on the planet in a bidirectional fashion as far as session initiation is concerned? Once you add that bit of reality to it, the scaling requirement goes down substantially. Wouldn't you agree? Trust me, I would like to just see us get it over with as far as IPv6 is concerned, provided we have a working, palatable IPv6 mh solution. But, man, I can't pass the red face test on a lot of these hypothesis :( Thanks, Christian The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: Request for Peering with AS4788 at Equinix SJO/ASH/LA
Um. TMNet is Telekom Malaysia. Used to be the PTT for Malaysia. Used to be the Malaysian government. I think they're privatized now. This would be a bit like saying British Telecom is passing bogus routes. While possibly true, it is unlikely it is intentional... Rgds, -drc On Jul 7, 2005, at 10:10 AM, Jason Sloderbeck wrote: We are peered with Equinix Direct and Internap in San Jose and have received a couple solicitations from random companies to peer, though we're not a provider of transit. I have no desire to find new peers, so I'm not considering the offer below -- just wondering if this is a red flag that's worth passing on. I am skeptical, but I suppose this could be harmless. FWIW, I've seen AS4788 on old CIDR reports under Possible Bogus Routes: http://www.ripe.net/ripe/maillists/archives/routing-wg/2003/ msg00146.htm l -Jason -- Jason Sloderbeck Positive Networks [EMAIL PROTECTED] From: Muhawira Muhamed [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 06, 2005 9:38 PM To: [EMAIL PROTECTED] Subject: Request for Peering with AS4788 at Equinix SJO/ASH/LA Dear Peering Admin, We are TMNet(AS4788) and would like to peer with you on EQUINIX/PAIX. Below are our details. ASNUM - 4788 AS Set - AS4788 Website - http://www.tm.net.my http://www.tm.net.my/ IP - (206.223.116.149) [Equinix-San Jose] IP - (206.223.123.63) [Equinix-Los Angeles] IP - (206.223.115.149) [Equinix - Ashburn] IP - (198.32.176.26) [PAIX-Palo Alto] IP - (195.66.224.47) [LINX - London] IP - (217.79.160.135) [XPE - London] IP - (210.171.224.194) [JPIX - Japan] IP - (192.145.251.44) [KINX - Korea] IP - (202.40.161.213) [HKIX - Hong Kong] IPv6 - (2001:7f8:4:0::12b4:1) [LINX - London] IPv6 - (2001:504:0:1::4788:1) [Equinix - San Jose] IPv6 - (2001:504:0:2::4788:1) [Equinix - Ashburn] Advertised prefixes (IPv4): ~ 215 Contact/Support : [EMAIL PROTECTED]/[EMAIL PROTECTED] NOC Phone : +60322404600 If you would like to set up peering with us please respond with your details and confirmation that you have set your end up and we will complete our end. If you have received this email twice then please accept our apologies. This would have been due to an outbound mail issue which meant we had to resend the email. Please let us know. Thank you. Muhawira Muhamed CORE IMPLEMENTATION DIVISION, TELEKOM MALAYSIA BERHAD (128740-P), TM Annexe, No.1 Lengkok Pantai Baru, 59200 Kuala Lumpur. Malaysia (+ 8 GMT) tel:+ 603 2240 3040 fax: + 603 2240 3234
Re: OMB: IPv6 by June 2008
I don't want to get into an SSL vs. IPsec argument, but... David Conrad [EMAIL PROTECTED] writes: Compare with SSL (works out-of-the-box in 99.999% cases, and allows both, full and hard security with root certificates etc, or simple security based on _ok, I trust you first time, then we can work_. a) I suspect most SSL implementations derive out of the same code base. I'd be surprised if this is correct. The three major SSL/TLS implementations by deployment are: 1. OpenSSL (used in Apache2, ApacheSSL, and mod_ssl) 2. Microsoft (used in IE and IIS) 3. Firefox/Mozilla (based on Netscape's NSS). These are all genetically distinct. In addition, there are at least three independent Java implementations (JSSE, PureTLS, SSLava). In addition, Terisa Systems (now Spyrus) independently implemented SSLv3 (though our v2 stack had some of Netscape's SSLref stack) and I believe that Consensus development did so as well. -Ekr
Re: OMB: IPv6 by June 2008
On the training issue. Everybody in our organization understands IPv4 at some basic level. The senior staff here myself included are conversant with IPv6 but you have the level 1 and 2 people who for the most part are not even aware IPv6 exists and there are a LOT more of them then there are of us and these are the people who are going to get their world rocked and who will need extensive training to be effective in a IPv6 world. Scott C. McGrath On Thu, 7 Jul 2005, Jeroen Massar wrote: On Thu, 2005-07-07 at 18:02 +0200, Andre Oppermann wrote: Jeroen Massar wrote: On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote: 4 - Retrain entire staff to support IPv6 You have to train people to drive a car, to program a new VCR etc. What is so odd about this? I had training to drive a car once in my life when I got my drivers license. I don't have to get a fresh training for every new car I end up driving throughout my life. You will have to get an additional license for driving a truck or even when you are getting a caravan behind that car of yours though. Motorbikes also have different licenses and you get separate trainings for those. They all have wheels, look the same, operate somewhat the same, but are just a little bit different and need a bit different education. You also either read something, educated yourself or even got a training to operate IPv4 networks, now you will just need a refresh for IPv6. You can opt to not take it, but then don't complain you don't understand it. For that matter if you don't understand IPv6 you most likely don't IPv4 (fully) either. If I need training to program my new VCR then the operating mode of that VCR is broken and I'm going to return it asap. Then a lot of VCR's will be returned because if there is one thing many people don't seem to understand, even after reading the manual then it is a VCR. It's that simple. Why are people buying iPod's like crazy? Because these thingies don't require training. People intuitively can use them because the GUI is designed well. So you didn't read the manual of or train yourself to use your compiler| bgp|isis|rip|operatingsystem| and a lot of other things ? IP networks are not meant for the general public, they only care that the apps that use it work, they don't type on routers. Protocols don't have GUI's or do you have a point and click BGP? :) Greets, Jeroen
Re: OMB: IPv6 by June 2008
Kuhtz, Christian wrote: On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. I would contend that is not true. What says that every device inside a company, family, enterprise etc has to be available and reachable by anyone on the planet in a bidirectional fashion as far as session initiation is concerned? Wasn't that the point of IP-Mobility? Take your one-and-only IP address anywhere you go? -- Andre
Re: mh (RE: OMB: IPv6 by June 2008)
Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. a shim layer seems like a promising enhancement. ietf-shim6 is taking an approach to a shim layer that will, I suspect, take some time to mature. I'd be surprised if it saw significant deployment anytime within the next 5 years, at the earliest. (a more ascerbic view would probably suggest that it is not even likely to produce a complete specification within that time, with deployment taking another 5 years...) the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: mh (RE: OMB: IPv6 by June 2008)
Dave, I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... $.02, - ferg -- Dave Crocker [EMAIL PROTECTED] wrote: [re: shim6] the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: OMB: IPv6 by June 2008
Christian, On Jul 7, 2005, at 11:02 AM, Kuhtz, Christian wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. Once you add that bit of reality to it, the scaling requirement goes down substantially. Wouldn't you agree? My feeling is that the question isn't how much memory, but rather how much CPU and bandwidth is necessary to deal with routing thrash. Yes, you can aggregate different things to try to reduce the number of entries, but that would seem to go against the general idea Alexei was suggesting. I mean, I'm an entity, and it'd be cool to have my own routed PI address and not have to deal with reconfiguring my network when I took my laptop from work to home... Rgds, -drc
Re: mh (RE: OMB: IPv6 by June 2008)
Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. -- Andre
Re: mh (RE: OMB: IPv6 by June 2008)
I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... i think we are agreeing. i think that any prediction that users will not use nats for v6 involves logic that can, at best, be called idealistic. naive would be another term to consider. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
RE: mh (RE: OMB: IPv6 by June 2008)
Given that shim breaks fundamental assumptions about the stable relationship between the packet header and the application context, there will be many security related issues to be resolved after the shim spec stabilizes. Shim is a 'more than a decade' effort if it ever completes. The disappearance of NAT is not as bad as the FUD that keeps coming up. See: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt and please send comments if some use of NAT is not covered. As far as alternatives for multi-homing, the IESG has focused on shim and denied a request for a bof in August to discuss interim options. I submitted updates to the ID editor early last month but for some reason they have not popped out yet, but I am always accepting comments on: http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-08.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-08.txt Like the approach or not, it is straight up existing BGP and existing host stacks. It will never be the highly optimized 400 entry routing table, but it doesn't pretend to be. It does however create PI space that has some hope of aggregating. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Friday, July 08, 2005 4:12 AM To: Kuhtz, Christian Cc: Joe Abley; NANOG list Subject: Re: mh (RE: OMB: IPv6 by June 2008) Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. a shim layer seems like a promising enhancement. ietf-shim6 is taking an approach to a shim layer that will, I suspect, take some time to mature. I'd be surprised if it saw significant deployment anytime within the next 5 years, at the earliest. (a more ascerbic view would probably suggest that it is not even likely to produce a complete specification within that time, with deployment taking another 5 years...) the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: mh (RE: OMB: IPv6 by June 2008)
Andre Oppermann wrote: Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: mh (RE: OMB: IPv6 by June 2008)
On Jul 7, 2005, at 3:41 PM, Andre Oppermann wrote: Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. Yes, but keep in mind that this benefit is completely unrelated to NAT's purpose as an address space extender. A stateful firewall with a very simple rule (permit anything originated from the inside, deny anything from outside except a few pesky protocols) would accomplish exactly the same goal. And it would be much easier to punch holes through when you needed to. From my perspective, the biggest benefit from home NAT devices is that they were a vehicle for delivering such a firewall to millions of windows boxes. Unfortunately, this drug comes with a number of harmful side effects, including nausea, blurred vision, and the inability to deploy a number of new protocols. -Dave
RE: OMB: IPv6 by June 2008
My feeling is that the question isn't how much memory, but rather how much CPU and bandwidth is necessary to deal with routing thrash. Sure. Resources in the end. Yes, you can aggregate different things to try to reduce the number of entries, but that would seem to go against the general idea Alexei was suggesting. I mean, I'm an entity, and it'd be cool to have my own routed PI address and not have to deal with reconfiguring my network when I took my laptop from work to home... Sure. But, you think the majority of employers feel warm and fuzzy about this...? I would say the answer is a violent hell no... Most security folks get moderately freaked out by people moving machines back and forth, let alone IP addresses. * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162
RE: mh (RE: OMB: IPv6 by June 2008)
Mangling the header did not prevent the worms, lack of state did that. A stateful filter that doesn't need to mangle the packet header is frequently called a firewall (yes some firewalls still do, but that is by choice). Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Oppermann Sent: Friday, July 08, 2005 4:42 AM To: Fergie (Paul Ferguson) Cc: [EMAIL PROTECTED]; nanog@merit.edu Subject: Re: mh (RE: OMB: IPv6 by June 2008) Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. -- Andre
Re: Request for Peering with AS4788 at Equinix SJO/ASH/LA
On Thu, 7 Jul 2005 12:10:46 -0500 Jason Sloderbeck [EMAIL PROTECTED] wrote: we're not a provider of transit. I have no desire to find new peers, so I'm not considering the offer below -- just wondering if this is a red flag that's worth passing on. Probably not. When I was at DePaul and when we connected to AADS I sent a lot of those types of emails to whoever the contacts were that were also connected there. Those that had open peering policies would often email back that they had already configured something and were ready when I was. Some, probably chuckling, never responded and some kindly sent back the equivalent of the Here is a link to our peering policy, if you can meet these requirements then sure (but we both know you can't :-) standard reply. Some organizations find it beneficial to peer with as many people as possible at the exchanges. The NANOG Peering BoF uses a partially derisive, but mostly humor intended term for these folks. John
Re: OMB: IPv6 by June 2008
On Wed, Jul 06, 2005 at 09:46:53PM +0200, Iljitsch van Beijnum wrote: We know how many IPv4 addresses there are. We know how many are unusable (although this number isn't 100% fixed). We know how many were given out. We know how many are given out now each year. What kind of magic do you expect will make this problem that's coming go away? Are there hidden pockets of yet undiscovered address space? Undiscovered? No. But unless the situation has changed since I last looked (which is possible), there are some sizeable clumps that will never get used by the people who own them, which it has not been practicable to reclaim. The tighter the vise, the higher the fence it will be worthwhile to jump to reclaim that space... just like prospecting for oil. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: mh (RE: OMB: IPv6 by June 2008)
Crist Clark wrote: And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. Any by connecting to one of the p2p overlay networks you'll have a few million in-use addresses momentarily. Pete
Re: OMB: IPv6 by June 2008
In message [EMAIL PROTECTED], David Conrad wri tes: Christian, On Jul 7, 2005, at 11:02 AM, Kuhtz, Christian wrote: What's the problem with independent address space for every entity (company, family, enterprise) which wants it? It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. Once you add that bit of reality to it, the scaling requirement goes down substantially. Wouldn't you agree? My feeling is that the question isn't how much memory, but rather how much CPU and bandwidth is necessary to deal with routing thrash. That's right. The issues are the complexity of the routing computation and the convergence time/stability of the routing computation as a whole. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: mh (RE: OMB: IPv6 by June 2008)
In message [EMAIL PROTECTED], Tony Hain writes: Mangling the header did not prevent the worms, lack of state did that. A stateful filter that doesn't need to mangle the packet header is frequently called a firewall (yes some firewalls still do, but that is by choice). Absolutely correct. Real firewalls pass inbound traffic because a state table entry exists. NATs do the same thing, with nasty side-effects. There is no added security from the header-mangling. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
RE: OMB: IPv6 by June 2008
At 1:02 PM -0500 2005-07-07, Kuhtz, Christian wrote: It doesn't scale. Regardless of Moore's law, there are some fundamental physical limits that constrain technology. I would contend that is not true. What says that every device inside a company, family, enterprise etc has to be available and reachable by anyone on the planet in a bidirectional fashion as far as session initiation is concerned? The problem is that you don't know, a priori, which devices will or will not need to be fully externally addressable. Even if we talk about just mobile phones, it's easy to imagine billions of devices world-wide that will need connectivity in the near future. Most devices won't need full bidirectional connectivity all the time, no. But it's also easy to imagine circumstances where you decide that you need to change the setting on the VCR or check the stove to see if you forgot and left it turned on. If you can give all the devices in your home full bidirectional connectivity (via a secure method, of course), then a whole lot of options open up that would otherwise not have been possible. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OMB: IPv6 by June 2008
Is it a pproblem keeping 500,000 routess in core routers? Of course, it is not (it was in 1996, but it is not in 2005 really? we have not seen this so how do you know? and it will be fine with churn and pushing 300k forwarding entries into the fibs on a well-known vendor's line cards? randy
Re: mh (RE: OMB: IPv6 by June 2008)
Petri Helenius wrote: Crist Clark wrote: And the counter point to that argument is that the sparse population of IPv6 space will make systematic scanning by worms an ineffective means of propagation. Any by connecting to one of the p2p overlay networks you'll have a few million in-use addresses momentarily. Preventing abuse of information available from databases maintained by P2P services is an emerging and interesting area of info sec. It may become more so as other means of harvesting live addresses become less productive. In The Future, the addresses of live hosts to attack may become an underworld commodity like valid email addresses are now. All of those are better than having Blaster or Slammer propagate so easily. At least make the malware authors work for it. If you were behind NAT, you couldn't use those P2P applications. So, yeah, you were safe on your limited-functionality, pseudo-IP, NATed connection from the Big Bad P2P. And if you still want the protection of NAT, any stateful firewall will do it. IMHO, if there is any reason NAT will live on in IPv6 it is the PI space issue. Even the NAP draft comes out and says, 4.7 Multihoming and renumbering Multihoming and renumbering remain technically challenging with IPv6... That plus the problems with the unique local proposals make it quite likely that NAT will not completely disappear should IPv6 become widespread. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: OMB: IPv6 by June 2008
a) I suspect most SSL implementations derive out of the same code base. definitely not! at least three major ones out there. randy
Re: OMB: IPv6 by June 2008
On 7-jul-2005, at 22:03, Jay R. Ashworth wrote: Are there hidden pockets of yet undiscovered address space? Undiscovered? No. But unless the situation has changed since I last looked (which is possible), there are some sizeable clumps that will never get used by the people who own them, which it has not been practicable to reclaim. Right. The tighter the vise, the higher the fence it will be worthwhile to jump to reclaim that space... just like prospecting for oil. Right again. And like prospecting for oil, at some point you're burning it up faster than you can prospect it. There are some 45 - 50 /8s assigned to single organizations. Let's assume for simplicity that those can all be reclaimed. That's 4 years at a /8 a month. So far so good. Then there are 40 - 45 /8s in class B space. That means 256 times as much effort to reclaim the address space, or reclaiming about 10 class Bs a day... Predicting is hard, especially when it concerns the future. But one thing is certain: we live in interesting times.
Re: OMB: IPv6 by June 2008
On Thu, Jul 07, 2005 at 02:55:08PM -0400, Scott McGrath wrote: On the training issue. Everybody in our organization understands IPv4 at some basic level. The senior staff here myself included are conversant with IPv6 but you have the level 1 and 2 people who for the most part are not even aware IPv6 exists and there are a LOT more of them then there are of us and these are the people who are going to get their world rocked and who will need extensive training to be effective in a IPv6 world. May be my view is quite limited. But just what exactly is soo hard about IPv6 other than hexadecimal and /128 space? Forget the NLA, TLA jazz, they are all deprecated as of RFC3587. CIDR at 128 bits and hex.. doesn't sound too complicated to me for any average networker dealing with IP subnetting. Most people who seem to have extensive trouble with IPv6 in my experience happen to have trouble doing CIDR subnetting in IPv4 as well.. But for average first-tier support, they just need to hear what IP6 addresses are being involved, and using regular network troubleshooting tools like they have been in IPv4. I don't see much issue with this other than theoratical nightmares thought due to the hexadecimal look. With regards to your comment about multihoming, your concerns are certainly valid and this goes back to the whole The Great IPv6 Multihoming Debate. Until it is resolved, some people are currently asking their upstreams to pass their PA space to their peers just like the way it is in IPv4. We currently do this for couple of downstreams who are multihomed but unable to justify for a /32 PI space at the time. As long as you get two larger v6 networks to pass along your PA space, you should be able to reach most popular v6 contents using multihomed path. I have a feeling, sooner or later, either scalable solution which can be implemented will be introduced, or customers will simply ask their uplinks to announce them or threaten to cancel service, just like in IPv4 world. James -- James Jun Infrastructure and Technology Services TowardEX Technologies Office +1-617-459-4051 x179 | Mobile +1-978-394-2867 [EMAIL PROTECTED] | www.towardex.com
