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