- NANOG - lists.nanog.org

MetroPAIX -- 55 Market San Jose
by Matthew Kaufman 29 Oct '03

29 Oct '03

If anyone on the list is connected to PAIX via the MetroPAIX product from 55 Market St. in San Jose, I'd like to hear about your experience. Please contact me off-list. Matthew Kaufman matthew(a)eeph.com mkaufman(a)dsl.net

1 0

RE: [arin-announce] IPv4 Address Space (fwd)
by Kuhtz, Christian 29 Oct '03

29 Oct '03

> The fact that something can be worked around with enough > footwork really doesn't make okay. Sure. Neither is it ok for VPN vendors to pretend as if NAT wasn't a part of daily life and reality. > Consider the congestion related behavior of TCP inside TCP. > Consider the additional perpacket overhead of TCP encap, and > the effect of the additional fragmentation that will happen > since few networks will pass datagrams over 1500 bytes. So? So fragmentation will happen. Look at all the existing DSL etc infrastructures where you do have to live with MTU molestations. Frag happens. So what. It still works nicely. What are we gonna do next? Whine about broken PMTUD? > If networks operators had demanded IPv6 in the past far more > products today would be enabled and the 'upgrades are > expensive' argument would be moot. Simply passing the buck > to the customer is not a globally wise solution. Sure. Simply ignoring present reality isn't a globally wise solutions. Hence we have broken VPN products incapable of dealing with NAT. Some are capable of dealing with NAT just fine, and are readily available. Enough said. VPN vendors incapable of dealing with NAT (which is really a quite simple fix, totally independent of the NAT box) should be terminated with extreme prejudice. ***** "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.61"

2 1

Re: [arin-announce] IPv4 Address Space (fwd)
by Dave Howe 29 Oct '03

29 Oct '03

Kuhtz, Christian wrote: > And there are workarounds for all those. NAT-T for ipsec is really intended for endnodes only - which is fine if you are doing the NAT yourself (typical medium/large company scenario - internal users shouldn't be using IPSEC, that is done at the gateway/firewall) but sucks if your cable or xDSL ISP decides NAT is the way to go. (usually followed by a "well, you shouldn't need two or more nodes there/want to run a server/care about SIP, a business should pay for a DEDICATED link" for a little three-man sales office in the backend of nowhere) But regardless, all the workarounds are doing is trying to patch the fact that UDP dependent connections are not NAT friendly by special-casing (or app-layer proxying) particular instances of UDP in a way that doesn't drop dead TOO often....

2 1

RE: [arin-announce] IPv4 Address Space (fwd)
by Kuhtz, Christian 29 Oct '03

29 Oct '03

Seems several commercial clients (such as Cisco's VPN client) offer workaround for that (tunneling IPSEC in a TCP session). Works great. > -----Original Message----- > From: Greg Maxwell [mailto:gmaxwell@martin.fl.us] > Sent: Wednesday, October 29, 2003 9:56 AM > To: Avleen Vig > Cc: Simon Lockhart; Dave Howe; Email List: nanog > Subject: Re: [arin-announce] IPv4 Address Space (fwd) > > > > On Wed, 29 Oct 2003, Avleen Vig wrote: > > > Indeed, and IPSec tunnels are frequently done between routers on > > networks, rather than individual hosts on networks (at > least in most > > multi-site enterprises i've seen). > > The most common use of VPN links is the roadwarrior. > IPSEC in this context is broken badly by NAT. Even when the > extensive hackery required to workaround NAT is enabled, it > still can not work in the case where two roadwarriors are > behind a single address connecting to the same VPN gateway. > > > ***** "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.60"

2 1

RE: [arin-announce] IPv4 Address Space (fwd)
by Greg Maxwell 29 Oct '03

29 Oct '03

On Wed, 29 Oct 2003, Kuhtz, Christian wrote: > Seems several commercial clients (such as Cisco's VPN client) offer > workaround for that (tunneling IPSEC in a TCP session). Works great. I'm sure I could also setup a PPPoEmail shim that would bypass most of these problems.. Who needs routers with PBR when you have sendmail with m4 configuration! The fact that something can be worked around with enough footwork really doesn't make okay. Consider the congestion related behavior of TCP inside TCP. Consider the additional perpacket overhead of TCP encap, and the effect of the additional fragmentation that will happen since few networks will pass datagrams over 1500 bytes. If networks operators had demanded IPv6 in the past far more products today would be enabled and the 'upgrades are expensive' argument would be moot. Simply passing the buck to the customer is not a globally wise solution.

1 0

RE: Anybody using GBICs?
by lance_tatman＠agilent.com 29 Oct '03

29 Oct '03

To be more clear, I'm specifically referring to Gigabit Ethernet Converters and not SFPs for POS or SONET. So, to reprhase, where in your network topology, are you using Gigabit Ethernet, specifically GE interfaces using GBICS? Are you using GE primarily for customer connections, server connections, peering points etc. ? Thanks to all who have already replied privately. -Lance- > -----Original Message----- > From: Haesu [mailto:haesu@towardex.com] > Sent: Tuesday, October 28, 2003 10:54 AM > To: lance_tatman(a)agilent.com; nanog(a)merit.edu > Subject: Re: Anybody using GBICs? > > > > On Tue, Oct 28, 2003 at 09:48:01AM -0800, > lance_tatman(a)agilent.com wrote: > > > > I'm looking into doing some research that will make use of > GBICs(Gigabit Interface Converters), > > interesting info too: http://www.nanog.org/mtg-0310/wodelet.html > > > but I need to know how many of you are using GBICs in your networks? > > If you are using them, where do they fit into your topology? > > Anyone who runs a provider network pretty much? heh.. > > We use them on all core routers and colo switch uplinks.. > > -hc > > -- > Haesu C. > TowardEX Technologies, Inc. > Consulting, colocation, web hosting, network design and implementation > http://www.towardex.com | haesu(a)towardex.com > Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 > Fax: (978)263-0033 | POC: HAESU-ARIN >

5 4

URGENT Merit NOC number required
by Narelle 29 Oct '03

29 Oct '03

Folks I URGENTLY need a phone number or other immediate contact for a Merit NOC contact particularly re the raddb system!! Like Now, actually. Correspond privately for my phone number if necessary!!! Narelle Clark narelle.clark(a)optus.com.au-nospam narellec(a)optusnet.com.au-nospam

1 0

Re: [arin-announce] IPv4 Address Space (fwd)
by Michael.Dillon＠radianz.com 28 Oct '03

28 Oct '03

>Some would ask, "What about increasing address usage?" Only the ones who weren't at the ARIN meeting in Chicago where we saw a chart showing that monthly consumption of IP addresses continues to decrease as it has since around the year 2000. >I would ask, "What evidence do you have that usage is increasing?" I would ask where's the evidence, period. Not much evidence in press articles and none in the ARIN article which was trying to tell people where to find evidence, not to make a case on the evidence. You've all heard of the CIDR report from http://www.potaroo.net Has anyone checked the articles there about IPv4 consumption trends? First written in July http://www.potaroo.net/ispcolumn/2003-07-v4-address-lifetime/ale.html Then updated for RIPE in September http://www.potaroo.net/presentations/2003-09-04-V4-AddressLifetime.pdf This was also presented at the Chicago ARIN and the slides will likely be on the web in a few days. The bottom line is that there are three different models which may predict when we run out of IPv4 addresses. The models predict dates ranging from 2022 to 2045. None of the models predict an exact year, they all predict a range of 4 to 8 years and the above dates are the earliest and latest of those ranges. >Does anybody have statistics for assigned-but-not-announced space? I'd be >willing to bet there will be more and more dead space over the years, and >in fact quite a bit of "increasing usage" is just churn. Some networks are actively growing these allocations. >Does anybody honestly think companies will commit the capex needed to >implement IPv6? Yes, because IPv6 is merely and incremental improvement, not a grand elegant solution to world hunger like ATM. Look at how we managed the incremental step of adding MPLS to our IPv4 networks. It was fairly painless because it uses the same boxes, the same people and the same management systems. And over time, the pain of doing MPLS is reduced because the bugs get worked out. Similarly, IPv6 is an incremental change that uses the same boxes, people and management systems. In fact, if you've put MPLS into your core, you only need to worry about IPv6 at the edge from the PE router to the CE router because you can use 6PE. The capex is being spent anyway by upgrading boxes to meet capacity needs. You didn't notice it but the new core boxes are all capable of IPv6 with a simple software feature upgrade. >if the people of this Esteemed Forum can't agree >that IPv6 is something that must happen ASAP, how will the PHBs (those who >control the money) and the customers (those who control demand) ever be >convinced? NANOG rarely takes the lead in new product development and driving market demand. Someone else will sort out that problem. >Hell, I can't even convince myself that IPv6 is neccessary. Is anybody out >there totally sold on IPv6, enough to evangelize it to anybody willing to >listen? I mean, IPv6 is no CIDR... I know that I said IPv6 is an incremental change, but the world that it enables is not incremental. Imagine 30 years from now where the majority of people in the developed world have full two-way voice, video, and data communications capability seamlessly integrated into their clothing, their vehicles, their workplace cubicles and their homes. X10 is obsolete replaced by IPv6 over power networks and IPv6 over Bluetooth v.3. Networks are everywhere and it is common for even small devices to have multiple IPv6 addresses. My belt (containing the cellphone transceiver) will have 20 IPv6 addresses in 20 different subnets corresponding to 20 VPNs. If you know about today's SIP networks, it's like having a phone number in INOC-DBA, FWD, SIPPhone, IAXtel etc. Except that these will be IPv6 addresses because they aren't for voice traffic. One of the 20 VPNs will be for a heart-rate monitoring service that coordinates with my gym and my personal trainer. Another one might be for an insulin level monitor that connects to my physician and pharmacy. The pharmacist will know when the insulin pack in my shirt collar will be depleted and will dispatch a refill to my home automatically. That's the problem that IPv6 is intended to solve. Providers with foresight can begin the process of upgrading today so that when IPv6 really is needed they will have a headstart. I'm not suggesting that anyone should rush IPv6 into production today, but everyone on this list should be running internal IPv6 trial networks to facilitate training of their personnel and to ensure that people have the experience needed to make rational and informed decisions about IPv6. In 1995, the Internet, a.k.a. IPv4 networks, took off with a boom and left the legacy telcos in the dust. If you want to recreate that, then keep your heads in the sand and other people will do IPv6 leaving you in the dust when critical mass finally arrives. It's that simple. --Michael Dillon

4 3

Heads up, and tell the banana eaters...
by Valdis.Kletnieks＠vt.edu 28 Oct '03

28 Oct '03

Another flare headed our way... Event #49 - 28 October 2003 Issued: 16:30 UTC, 28 October 2003 SOURCE EVENT Class X17.2 Flare in Region 486 at 11:10 UTC on 28 October 2003 Type II: 1250 km/sec Estimated LASCO-derived Plane of Sky Velocity: 2125 km/sec ESTIMATED TIME OF ARRIVAL OF SHOCK AT EARTH Estimated Impact Window: 00:00 UTC on 29 October to 21:00 UTC on 29 October Preferred Predicted Impact Time: 08:00 UTC, 29 October 2003 (3 am EST on 29 October) Estimated Shock Strength (0=Weakest, 9=Strongest): 9 Predicted Behavior of IMF at Shock Impact At Shock Impact, the Interplanetary Magnetic Field is predicted to initially turn: SOUTHWARD IMPORTANT TIME OF ARRIVAL NOTICE FOR NORTH AMERICANS The preferred time of arrival is ***TONIGHT***, TUESDAY NIGHT (before you go to bed that night) near or after 3 am Eastern Standard Time). That's 2 am Central Standard Time on TONIGHT. That's 1 am Mountain Standard Time on TONIGHT. That's MIDNIGHT Pacific Standard Time on TONIGHT. EXPECT RESIDUAL ACTIVITY (LESS INTENSE) TOMMORROW NIGHT (WEDNESDAY, 29 OCT) AS WELL ! EVENT #49 NOTES: This is the most energetic Earthward-directed event of the solar cycle. SEVERE to MAJOR geomagnetic storming is expected to abruptly commence following the arrival of the shock front from this flare. This flare was associated with a Ground-Level Event. It was also associated with very high energy protons at greater than 100 MeV (which are still climbing, over 5 hours after the event began). A magnetic crochet was observed over the daylit sections of the ionosphere. An exceptionally intense shortwave fadeout and polar cap absorption event are in progress. There are reports this event was observed in white-light. Intense radio bursts were associated with this event across the spectrum. The type II shock velocity is not representative of the observed velocity of this CME. The observed velocity as determined by SOHO was 2125 km/sec. This event has the potential to produce the strongest geomagnetic storm since 1989. Auroral activity could become visible into the deep low latitude regions. This one is worth driving a good long distance over to find clear skies. It has better potential to produce low-latitude aurora than almost any other event observed in the past decade. Keep in mind that it is also possible the disturbance may not be nearly as geoeffective as many would like. It all depends on the character of the magnetic fields imbedded within the coronal mass ejection. However, we believe it will either be very large, or only modestly large in terms of its capacity to produce disturbed geomagnetic and auroral activity. We do not expect this disturbance to be small. These predictions may be based on preliminary data and may be revised without warning. The predictions should not be used as a definitive indication of CME impact times or strengths and may frequently be in error. The proprietary methods used to estimate shock impact times are under continual development. Caution is advised.

1 0

RE: [arin-announce] IPv4 Address Space (fwd)
by Kuhtz, Christian 28 Oct '03

28 Oct '03

> >> Does anybody honestly think companies will commit the > capex needed to > >> implement IPv6? > > > William Leibzon wrote: > > Not without additional benefits. > > I agree, and they're all gone now. To my deepest regrets, > IPv6 has become nothing more than IPv4 with more bits (it's > actually worse than IPv4 as of today). Excuse my rambling and what some may consider heresy even :), but.. One question to ask is whether IPv6's approach is the right one, furthering a particular way of doing things rather than really reinventing itself. Do I really need global awareness of address space? Why isn't address space a tool, services is what you're really after, and why not build an infrastructure centered around context of a service rather than reachability of an address? If we're going thru all this trouble in providing support for it, why not make it a more revolutionary approach? Is it really realistic to have some of the features in IPv6 employed in the way they are designed? The debate around NAT in IPv6 circles clearly show that there's an (more or less) academic desire to expose every address on the planet to every other. Is that truly required by way of the way IPv4/v6 work today? There are very convincing arguments to be made to say that this isn't desirable and that I don't particularly want everybody to get to every address (and once you accept that unrestricted, 100% reachability of every globally assigned address is unrealistic, many of the arguments behind the need for vast address space go away..). I really don't necessarily care what somebody's address is, if or if not it gets translated, as long as reachability exists.. So, as long as I can make the service work, what does it matter? Per hop architectures do seem to work nicely. The addressing allocation debate and that we to this date do not have a fully functional and working 'multihoming address space to multiple providers' approach that matches reality is another problem to be solved. And notions that try to explain the need for multihoming away rather than admitting that strictly hierarchical address space may be a dead end path and that a new solution is needed, are disturbing to me. Both of the last points are real issues, IMHO, not just rambling. And, no, I don't have a solution to instantiate right now and here, but I do have some ideas as to what I would or would not like to see included in a solution. I'm not saying IPv6 is dead, but I think a leap, rather than an incremental improvement may be needed. Unless somebody actually does come up with an IPv6 killer app... My $.02, 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.61"

2 1