|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical NANOG36-NOTES 2006.02.12 talk 5 IPv6 --fear and GOSIP in Dallas
Apparently the video feed is of very good quality this time around--many thanks to Brokaw for the good bandwidth to the hotel! Last set of notes before lunch. Matt 2006.02.12 NANOG IPv6 transition panel panel member briefs at http://www.nanog.org/mtg-0602/golding.html IPv6: time for transition, or just more GOSIP? GOSIP was initiative to use OSI networking throughout the government. 5 participants Joe Houle ATT Jared Mauch NTT America Wes George, Sprint Jason Schiller, UUNet/Verizon Fred Wettling, Bechtel Tried to get government people, since they went v6, but they're not forthcoming with details; you know how government people are. :D Daniel Golding, The burton group Joe Houle, ATT is up first. Emerging service for ATT for L2/L3, IP private networking, v6, etc. fall under his baliwick. He'd count himself as pragmaticlly pro; IPv6, why now? He does believe we're running out of IPv4 addresses. NATs and non-unique addresses make offering quality services difficult. Convergence doesn't work well over NAT'd addresses. why governments? US government doesn't want the have-have-not split to continue; the v6'ers may be the "have" side and we don't want to be on the have-not side. NTT America (AKA 2914) Native dual-stack IPv4/IPv6 since fall 2003 Cisco 7200, 7500, "76k" Juniper M series, T-series Wes George, Rob Rackell hat, couldn't be here due to weather. Pro v6, looking at it with skepticism. Sprint close to center of v6 world. 200pps on v6 network. Internet doesn't use v6 for real yet this is not the movie as the ISO fun; this time the government is paying! IPv6 is something that US carriers can make money on in the VPN space It is not valuable as an internet transport yet spend less time marketing about how cool it is, and go fix the issues!! multihoming, micromobility, SHIMv6 is a host solution. This time around, the government is paying. They don't know exactly what they want, but they know they want it. hoping carriers will figure it out and tell them. Jason Schiller, UUnet/Verizon. public v6 roadmap. AS284 US/AS12702 EMEA/AS18061 AsPAC) for v6 only Over network utilizeing GRE Phase 2 6PE solution in AS701 dual stack v4/v6 on edge mail, DNS support later phase 2a upgrade exising non-6PE capable edge routers 2007, phase 2b native v6 in the core (maybe) Problem is, no money yet in v6, so can't roll out aggressively at all. But if no money, why put it in the core? Well, to be ready in case it DOES take off in the future. Fred Wettling, Bechtel--large enterprise, also with v6 business council. Bechtel Telecoms (A & C for big carriers like Sprint, ATT, etc). Interested in non-traditional transport of IP services. shift in plant automation networks from proprietary to IP; so want to be ahead of the curve on it. Bechtel's internal test started last year, will be deployed out to 40,000 by this year; a bit of the chicken and egg issue, go back to 1995, IE v1 vs today; things will progress, things will take off, the goal is to be ahead of the curve. Daniel Golding, host for the panel. Question 1: Why IPv6, why now? Why are you implementing v6, other than it's cool? Is it address exhaustion, new capability, Gov't RFP requirements, vendors pushing new hardware? Jared notes they rolled it out in 2003 due to global pressures; they wanted to keep a unified network model worldwide, and as a subsidiary of a japanese company, and the largest player in that space, combined with government mandates, really pushed them in that space early. It _is_ a technical cool thing, it's good to be a market leader. Jared notes that they've been running dual stack v4/v6, it just works. ATT VoIP has been a driver, just doesn't work over NAT, so what other solutions are there? Really, address exhaustion, non-unique addresses propagating throughout space is just putting roadblock after roadblock in front of convergence. Dan asks why do we need NAT--we're not OUT of v4 addresses yet; Joe notes that people are really using NAT as a security mechanism right now, more so than really worrying about conserving address space. Yes, it's bogus, but it's what people have been sold on right now, so it gets widely used. Jared pitches in and notes that the push for encapsulation of everything encapsulated over port 80 is getting more and more widespread. People are attempting to use "firewalls" and "NATS" to give themselves the notion of security, even though most infection rates now are coming from other vectors (spyware, infected email, etc), rather than outside probing. Dan notes we don't need to do NAT, they can go to their upstream, to ARIN. But ARIN frowns on using public space for private use? Bechtel notes they're running into more and more problems as they try to get companies to do joint ventures, as every company uses 10.x space, and they have to do NAT over NAT, it's evil. He's also an IMOD (infrastructure modernization) player, it's a 4 billion dollar upgrade for the military, and it has a specific subsection about using v6 to avoid that problem. Also, intercorporate and collaborative efforts are exposing more and more info to the outside, with DMZs, etc. We need to make sure security is being correctly approached, NOT from using IP addressing tricks, but rather correctly. Jason notes v6 is also a "young", "fresh" stack which is nice. But Dan isn't sure that's a benefit per se. Joe would like to be able to use the flow label header, get beyond diff-serv level to get application aware network. Right now, just a bunch of bits, but since it's build into the header, it could really provide some real value add. Fred notes it's like people asking 12 years ago "what's the value/benefit of the Internet?" There will be things that will come out that we can't imagine yet once we start deploying it. Asking "like what" is asking us to imagine what we haven't conceived of yet. Fred notes that v6 will actually be simpler for many of their company-to-company connectivity. Toshiba, I300 TV, 3 ethernet jacks on it, it speaks v6, now carriers that speak v6 don't need redundant services, it can all be handled through the one link. Can't do that easily on v4. Dan notes multihoming for non-LIRs isn't doable under v6 at the moment, and that seems to be one of the holdups. People at last NANOG didn't like the shim6 solution. But enterprise multihoming is a customer requirement, people aren't willing to give that up. If only the big guys can get v6 space, we won't get widespread adoption. Joe notes shim6 is the only thing in the works to support multihoming. But Dan notes that the big content players like Yahoo have rejected it, since their servers don't have resources to handle 1800+ addresses on each server. Jared notes that even though we don't want to keep upgrading our routers, there's no other sane path that we can see. But Joe notes there's potential for explosion that scares him. It *could* happen. Someone could deaggregate the v4 space, though, and Jared notes it could blow up our current routers already today. So what about measuring fragmentation in v4 world today, vs in the v6 world, and can we accept that? Jared notes we'll come to a consensus on it, the way we did with CIDR and Sprint's filters for v4 space for a long period of time. Verio was one of the players holding that line for a long time. Fred notes business council will chime in on PPML soon. Bechtel has 40 different ISPs around the world; their network changes on a regular basis; trying to add and subtract address space each time a carrier comes or goes will be a major headache. Bechtel would like to work with carriers to advertise their netblocks, and namespace, NOT add a headache on re-addressing every time they switch providers. Bechtel got their IPv6 space via ARIN. They build turnkey solutions for owners, they operate as an LIR from that aspect since they turn over address space with the plants they build to their customers. Jason speaks up about number of 24s in table, vs number of 48s possible. About 16 million /24s in v4 space. 137 billion /48 blocks in v6 space, so about 2 million times more /48s than /24s. customers might go shorter than that to do traffic engineering. So, what is Verizon's answer? Couple of answers: Tony Hain--multihoming in v6 just works, do it, let the routers keep up. Jason's personal view is that we need another solution; we can't risk networks blowing up, but shim6 does seem pretty broken. Wes notes memory is pretty cheap, in general. But specific memory, like TCAMs, are more expensive, as are custom ASICs. It's like building a network based on classful fast path forwarding; the problem there is starting from bad assumptions. Sprint is adhering carefully to the RFC that Rob wrote a while ago, about announcing the top aggregation, nothing more. That limits even PA multihoming, really. Dan rephrases, do you think most providers will only announce their block, or will they leak more specifics? Jared encourages people to filter on RIR boundries; if ARIN says they only allocate /48s, then filter on that, and only accept up to that size. Customers have come pressuring them to allow announcing their /64, but that's just silly. Verizon--taking queue from IETF/ARIN, aggregation is the holy grail, so they only advertise their aggregate. To the global internet, only send the aggreate. That's the policy thus far. If people start putting /48's into the global routing table, will show that aggregation isn't the holy grail, will probably mean we do the v4 model. Joe is on the edge; he agrees, but he's worried about the slipperly slope. Fred notes if we have a brick wall, we won't go anywhere, at least on a slipperly slope, we'll get some movement; he can't be locked into IP space locked into providers, he works with hundreds of companies around the world. Wes--VPN advances will probably move v6 forward, as will government, more than in "normal" IP v4 model. Less FUD driven. IS it NANOG's problem? It's a plumbing problem, and we're a bunch of carpenters. It's an IETF problem, more than a NANOG problem; but they haven't given us the right tools to work with. But trouble to see ROI for operators to go to IETF, for vendors much easier to see the ROI. The operators need to get involved in listing requirements for protocols, before the work even gets started. Bunch of people run for the mikes: Joel Yagli, UofO; for all: looks in routing tables, doesn't see that many routes, even if people do some deaggregation, probably won't see that many routes. In context of shim6, carries more state in hosts; much more problem to put pain in thousands of hosts; upgrade smaller number of hosts, rather than larger number of hosts. What about I2 v6 view? They get block from their upstream, they get no multihoming option. it's important in the v4 space, but not in v6 yet. No plans to upgrade to shim6 on their hosts, no. 170K internet routes. Add 150K internal v4 routes, you're into 300K routes for v4 table. Add to that the v6 space, assuming one aggregate and deaggration based on v4 model. 24K aggregates, 35K deaggs, would add another 70K. There's about 59K intentional deaggregates happening in the v4 space today. If you add all that up, and do 2547 entries in FIB, the v6 contribution is very part of the problem. Jason notes that vendors currently claim their boxes Bill Woodcock--Bechtel has IPv6 space, some other large enterprises that have their own v6 space. In ARIN region, only way to get v6 space is to assert that you will have a large number of v6 customers imminently. If you would like ARIN policies to be updated to reflect reality, would be good to get more involved with ARIN policy--please!! Fred notes the only sustainable model for them was to get their own allocation, given that they work with so many end-customers. Ted Seeley, Sprint. Aimed at Jason. Scale of infrastructure. Entire v6 space fits in 256K of TCAM right now. Jared, have you done homework on how often they will need to upgrade their linecards? They do upgrades to handle v4 traffic, and the v6 upgrades come along for the ride. But for 200pps, don't need to worry today about v6 traffic. When v6 takes off, it *will* deaggregate, there's no stopping it. How will it be handled? The deaggregation in v6 space is unlikely to be as bad as in the v4 space. May see a boom where people need more space, may need to deal with it then. But people are finding the same challenges with 2547 customers with thousands of RFC1918 addresses and route targets in VRFs to keep track of? It's a problem overall, why is v6 being singled out? You'll have the same growth potential in the v6 space, and if something has to be tossed out, it might as well be v6, because everything else has revenue associated with it. Steve Feldman, CNET, medium sized content company. If the internet goes away, they get no revenue. management mitigates against internet going away by having many upstreams. They need to multihome, they don't care "how" as much, they have to do it. If there isn't a multihoming solution in place for v6, companies just won't move to it, period. Their upstreams that do provide v6 space won't allow multihoming. John Curran, IP directorate, 1993/1994, it's been going through evolutions for years. ARIN chair, they pay attention in board meetings, they verify applications in both v4 and v6 space. As we go through v4 address depletion in coming years, the stringency for new allocations will increase. What should ARIN do to their peers to ask for more IPv4 addresses, vs IPv6 allocations. Randy Bush, IIJ; considering that number of v6 allocations has more hosts behind it than the number of bits moving across it. Rob Seastrom, speaking for/and about himself. He runs v6 in his AS. The router is subject to being cannabalized for v4 router until there is content on v6 and there is multihoming for v6. Rough consensus and working code has been replaced by analysis paralysis. Tony Hain--part of reason for analysis paralysis is initial requirements were conflicting; network and endsites had conflicting requirements, so is there any wonder the compromise that resulted is not to anyone's liking? The IETF is spiralling out of control due to lack of feedback from operators in the IETF process. Fear is mentioned over and over again. Fear of what could happen if we allow PI space. He's had a draft of a different way of looking at problem in a different way. Allow for people you "care" about to have a routing slot; how do you distinguish big guy from little guy you can aggregate in a sane and fair way? Is mythical global routing table really real? route-views would say it's not. If we're not willing to step up to IETF and make our voices heard, we'll be stuck with a broken protocol. Ted Seely notes the vendors monopolize the IETF and want to sell boxes, not make working code!! Joel Yagli, timeframe for reachitecting the global routing table for v4/v6 isn't relevant; if we keep talking about this in 10 years, we're screwed. Randy notes we've been saying that for 10 years. There are people who have been working for 15 years to get paradigm changed, and they're tired of wading back into the cesspool yet again!! They've shed blood in that process, and the food isn't even that good! OK, that wraps up the panel, many thanks to everyone, including Dan for chairing it--very good, very active panel! Dead wireless unit at front of room,, will be fixed over lunch. Be back at 2pm for tutorials!
|