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!