The NANOG Program Committee is pleased to announce that the
agenda for the upcoming meeting in Bellevue, WA has been posted:http://www.nanog.org/mtg-0706/topics.html
If you haven't already registered to attend, now is a great time!
Sorry to post 4 times this year, and really, it just kind of stuck out when
I went to look at the agenda, but:
Nothing about V6? Not a workshop, tutorial, or even a panel? Any reason why?
Is V6 not happening?
Best,
Martin
you have something new and interesting about ipv6? if so, did you submit?
randy
If you are going to stand at microphones at other groups meetings and
take credit for turning on the first v6 network, perhaps you should be
asking yourself this very question?
My colleagues and I need some training. We don't have the experience.
I'm asking because we want to see this at NANOG and I'm wondering why
there isn't. Exhaustion from ICANN to RIR's and then to users is real,
and it's happening. Help.
-M<
Given the ARIN statement, I think it's time for more discussion of v6
migration, transition, and operations issues. No, I'm not volunteering;
I'm not running a v6 network. I suspect that Martin is right -- the
program committee should be proactive on this topic and seek out
presenters.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Agreed. The statement from ARIN is recent and impacts us all. We've
got our core v6 routing in place, but operationally, that's really the
easy part. Modifying the tools such as billing, monitoring, management,
tracking, and auditting are the slow link in the chain. The space is
dwindling but that doesn't seem to be putting the transition pressure on
if the services aren't there to use v6. Until more transit providers
support it, the reasoning for smaller provider to transition is limited.
Eric Krichbaum, PhD
Director Network Engineering, Citynet
Steven M. Bellovin wrote:
you have something new and interesting about ipv6? if so, did you
submit?Given the ARIN statement, I think it's time for more discussion of v6
migration, transition, and operations issues. No, I'm not volunteering;
I'm not running a v6 network. I suspect that Martin is right -- the
program committee should be proactive on this topic and seek out
presenters.
If you want somebody to 'present' something about IPv6 transition, then
probably the first step is to start indexing what the current problems
are for ISP's and then kick the people who can explain that...
From the top of my head, it starts by upgrading:
- Routers
- Management Tools
- Monitoring Tools
- CPEs
- Getting proper transit
- Loadbalancers and other net infra
- and other things I forget here
For core links it should IMHO be mostly possible to keep them IPv4/IPv6
dual-stack. When that is not the case one can always do minimal tunnels
inside the AS. Same for getting transit, it doesn't have to be directly
native, but when getting it try to keep the AS's crossed with a tunnel
for getting connectivity to a minimum (See also MIPP*).
Towards endusers it can become nasty, eg it would require upgrades of
the CPE and also the infrastructure might need to be upgraded. For Cable
systems only recently the Docsis 3.0 standard was released and that
would still require a lot of upgrades. Tunneling those users might be a
way to provide IPv6 connectivity to these users without much ado. There
are of course a lot of transition mechanisms, each with their pro's and
con's and all depending on what one wants to achieve.
When there is connectivity, the next step is to start upgrading
services. First upgrading the actual servers that these services run on,
then enabling the services to support IPv6 and starting to stick them in
DNS. The latter point of course can become nasty. When a customer's
client (eg Internet Explorer/Firefox) has IPv6 support and it thinks it
can connect to the service as it sees a AAAA record, but the link in
between doesn't work. Resulting in a unhappy customer as "it is broken"
and they really can't care what is broken and they should not. Care is
thus to be taken when upgrading these services, as it might cause a lot
of helpdesk calls.
Probably doing a trial on the customer base, especially having a group
of people who will give good bugreports and enabling them to use it, is
a good idea. A trick that might work there is to provide those people
with alternate caching DNS servers which do return AAAAs. This can thus
automatically be done using DHCP, when you have a user who is IPv6
enabled, steer them to the DNS servers that return AAAAs and presto,
they start using it. And when you are lucky it also actually works.
And of course that is not all, reading a good book and other materials
on this subject and doing trials and testing is of course a good thing
to do, but one should have done that in the last 5 years already...
<spam>Lastly, don't forget to signup to GRH so that you can see how the
status of your BGP is holding out :)</spam>
Greets,
Jeroen
* MIPP = http://ip6.de.easynet.net/ipv6-minimum-peering.txt
Yes that document is already 5 years old by now, there where people
already then who where thinking about those things 
Furlly agree.
Time is very short, but if that help I will volunteer to work on something
(workshop, panel, etc., or even all together). Of course, it will need to be
agreed *immediately*.
Regards,
Jordi
Jeroen Massar wrote:
Steven M. Bellovin wrote:
you have something new and interesting about ipv6? if so, did you
submit?Given the ARIN statement, I think it's time for more discussion of v6
migration, transition, and operations issues. No, I'm not volunteering;
I'm not running a v6 network. I suspect that Martin is right -- the
program committee should be proactive on this topic and seek out
presenters.If you want somebody to 'present' something about IPv6 transition, then
probably the first step is to start indexing what the current problems
are for ISP's and then kick the people who can explain that...
I would vastly prefer to here people talk about what they are doing
rather that hear the same set of usual suspects talk about "what we
should be doing". The later is tiresome and we have a decade worth of
examples of it to pick through.
Joel Jaeggli wrote:
[..]
I would vastly prefer to here people talk about what they are doing
rather that hear the same set of usual suspects talk about "what we
should be doing". The later is tiresome and we have a decade worth of
examples of it to pick through.
Well, what I described is what I already did quite some time ago, just
very briefly summarizing what it takes to get there.
The folks who already started or are already done deploying IPv6 are not
the ones who need the attention. The ones who haven't yet though, now
they are the ones who need to quickly still step over all the hurdles so
they get back on track.
=46rom a network operators point of view, IPv6 is just like IPv4, it work=
s
and it has it problems and you need the expertise and experience to know
how to resolve those. Nothing more nothing less, except that the
addresses are a bit longer...
See that all, like the rest of NANOG, as helping out fellow colleagues;
one could of course also simply say: they didn't bother for the last
couple of years, so why should the rest of us care about them? From a
economic/competition point of view that is actually not even such a bad
idea. Defies a bit what NANOG is about though
Greets,
Jeroen
I would urge potential sponsors to insist that V6 is on the agenda as
a condition of funding, both meeting sponsors and Beer 'N Gear.
-M<
it is possible that vendors might not want that story told on their
behalf... there are still a significant number of vendors without any
story for v6 
(without a reasonable story I'd say)
I think you're missing a few things here.
(subset of CPE --)
- "Firewalls" and NAT (wasn't v6 supposed to stop the latter)
- end-hosts (Grandma still using unpatched win98/winME isn't going
to be looking at the ipv6 pr0n project anyways.. or is she 
- DDoS Mitigation devices (where's my ipv6 capable "guard"?)
the good news is there's a mostly reasonable story for most
folks under the CPE, Transit, "Core" Routers (subject to a caveat matrix),
Monitoring and Management.
It does require some upgrades to these systems, which depending
on things, could cost some money. I'd love to see google or Y! with
an AAAA record. Or even Microsoft
It'd be cool to see the number of folks still using busted
resolver software who says 'google is busted' and the rest of the world
will see it continue to work without trouble. It's going to take
someone like them to help shift things. (or even akamai ;))
- jared
Speaking as your representative of the ipv6 pr0n project (http://www.ipv6experiment.com) I thought I'd chime in here, as well. 
I hoped to be at a point with our experiment to be able to give a presentation at this NANOG(if it would be accepted, anyway), but some financial and technical setbacks have slowed us down a bit. A few of our offers of free transit for the experiment seem to have fallen through, as well as a few unrelated issues taking up most of our free time slowing down the progress of the custom software for it.
That said, one of our definite goals is to measure things like:
* What problems the average end user has after turning IPv6 on, no matter what method they're using for it. (Native connectivity, tunnels, 6to4, etc)
* What issues we have trying to leverage a ton of off-the-shelf software (log analyzers, monitoring tools, discussion forums, etc) just getting this experiment accessible over v6.
* We're going to try to touch on every piece of the IPv6 landscape in one way or another, and document what problems we run into. End user software/CPE support, transit issues, peering issues, server software, router configuration, etc.
* What breaks on the user side just by turning v6 on? What breaks on the server side?
* How much worse download speeds are on average over v6 than v4, for users motivated to download large files?
So, while I can't do anything for this NANOG, I do plan on presenting our results at whatever *NOG will have us when the experiment is complete. If there are any avenues of interest that you specifically want more information on "what would happen if we had to deploy v6 now" kinds of things, we're in a position to tell you. Just let me know and I'll find some way of measuring/surveying/documenting it.
-- Kevin
i agree 100%, which is why I posted something similar almost 2 years ago
now It'd be very good to get some actual content on v6 that the masses
want to view/use.
Krichbaum, Eric wrote:
Agreed. The statement from ARIN is recent and impacts us all. We've
got our core v6 routing in place, but operationally, that's really the
easy part. Modifying the tools such as billing, monitoring, management,
tracking, and auditting are the slow link in the chain. The space is
dwindling but that doesn't seem to be putting the transition pressure on
if the services aren't there to use v6. Until more transit providers
support it, the reasoning for smaller provider to transition is limited.
And give that most end user allocations are /64s, could bind really handle a 18,446,744,073,700,000,000 line zone file? 
you have something new and interesting about ipv6? if so, did you
submit?If you are going to stand at microphones at other groups meetings and
take credit for turning on the first v6 network, perhaps you should be
asking yourself this very question?
first, i did not say i turned it on. i said the company for which i
worked did.
second, nothing new and interesting about ipv6 of which i am aware.
My colleagues and I need some training. We don't have the experience.
I'm asking because we want to see this at NANOG and I'm wondering why
there isn't.
wow! you missed the one day workshop in the lacnic meeting you just
attended? bummer.
what would a nanog v6 workshop contain? especially given the excellent
tee shirt "96 more bits, no magic?"
randy
Isn't the driver going to be scarcity and/or expense of v4 addresses?
-M<
-M<
Sure, but it's not as simple as just giving v6 addresses to end users one day, even if your entire network and backend systems support it.
If you were an end user, calling up your ISP to get a new DSL line, and were told you couldn't have an IPv4 address, only IPv6, and "Sorry sir, Google (etc.) won't work until they upgrade." would you:
a) Stick it out with that provider, even though there is no content for you to access.
b) Hang up.
If you answered (a) to the above, run through that again, from say, your Mother's perspective.
Now that NAT-PT is deprecated (ie. can't be used as an excuse to not move), we need to move the large (and small) content providers to dual-stack, before we move any customers to v6-only. Content providers have all the IPv4 addresses they need already, they're not going to be asking for more any time soon. If someone has some bright ideas on how to transition without loss of service to *someone*, I'm all ears.
(IPv4 NAT is not a bright idea.)
In addition, when 2010 [1] rolls around, are the free CPE that your customers were given in the last 7 days upgradable to support IPv6?
This is, of course, assuming we don't hold off until we've got a different IPv6 architecture as a result of the RAWS stuff. [2] While we're here, can someone point me in the direction of any ongoing discussion/work in this area? I attended the APRICOT workshop, but where to go to keep up with things/get involved isn't obvious.
I agree, it is *right now* one of the main drivers.
In addition to what I'd mention yesterday about a possible workshop or
panel, I've prepared an extensive document (21 pages at the time being)
about the IPv4 exhaustion and all the temporary/permanent "mitigations",
results they could provide and how much they could take. So I can easily
prepare a slide set for that if it is interesting.
Regards,
Jordi
Nathan Ward wrote:
[..]
Isn't the driver going to be scarcity and/or expense of v4 addresses?
Sure, but it's not as simple as just giving v6 addresses to end users
one day, even if your entire network and backend systems support it.
Why not? If folks are still using Windows 98 by then I surely hope
they can't have any connectivity to the Internet. The word "SpamDrone"
comes to mind for those old versions. As Windows XP is already out for
the last couple of years and has fully working IPv6 support, Vista is
there also with fully working IPv6 support, the OS should definitely
not be a problem anymore. For folks without money, all the Open
Sourcish OS's also do IPv6 perfectly fine, some even already from the
installer.
If you were an end user, calling up your ISP to get a new DSL line, and
were told you couldn't have an IPv4 address, only IPv6, and "Sorry sir,
[..]
Your grandma really doesn't know what "IP" is, nor will she ever care.
Ever heared of this thing called "HTTP Proxy"? That solves 90% of
those issues. Takes care of mail also as most intarweb-users are using
webbased mailers anyways. They work perfectly fine and can do IPv4 and
IPv6, using IPv6 as the transport.
Otherwise, you can always abuse http://ipv6gate.sixxs.net or
http://ipv4gate.sixxs.net for the other way around.
Now that NAT-PT is deprecated (ie. can't be used as an excuse to not
move), we need to move the large (and small) content providers to
dual-stack, before we move any customers to v6-only. Content providers
have all the IPv4 addresses they need already, they're not going to be
asking for more any time soon. If someone has some bright ideas on how
to transition without loss of service to *someone*, I'm all ears.
(IPv4 NAT is not a bright idea.)
What about looking up the word "transition" in the dictionary and
comparing it to "flag day". There is no flag day, it will all be
gradual. Some people have been providing commercial IPv6 connectivity
already since as early as 2001 (and some even earlier!)
Also, if you want to provide those users IPv4 access, you can always
hurdle them behind an IPv4 NAT. They are used to that today already
anyway.
In addition, when 2010 [1] rolls around, are the free CPE that your
customers were given in the last 7 days upgradable to support IPv6?
You should have thought about that already, like, 5 years ago!?
Also, you can always just TUNNEL over them. RFC1918 or something
similar to the enduser and then provide them with a NAT to have a
public IPv4 address so that they can reach legitimate resources.
Then provide them with a tunnel so they can use IPv6 in full strength.
But that is a doomsday scenario. Running out of addresses doesn't mean
that IPv4 stops to work.
This is, of course, assuming we don't hold off until we've got a
different IPv6 architecture as a result of the RAWS stuff.
Routing and addressing should be separate. Providing blocks of
addresses to organizations that can justify the need for them is
great. Reforming the routing system is a thing that can be done later
when there is somebody who find the magic bullet that folks will
accept. Can take some time of course, but up to then it appears that
vendors of routing equipment can scale...
[2] While
we're here, can someone point me in the direction of any ongoing
discussion/work in this area? I attended the APRICOT workshop, but where
to go to keep up with things/get involved isn't obvious.
As mentioned in various places:
ram@iab.org, see https://www1.ietf.org/mailman/listinfo/ram
Greets,
Jeroen