Re: shim6 @ NANOG

From: Kevin Day (no email)
Date: Sat Mar 04 2006 - 08:07:48 EST

  • Next message: Kurt Erik Lindqvist: "Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]"

    On Mar 4, 2006, at 2:21 AM, Iljitsch van Beijnum wrote:
    >
    >> ... which is what I expect to happen. A few folks will see it
    >> coming, design a fix, and everyone will deploy it overnight when
    >> they discover they have no other choice. Isn't that about what
    >> happened with CIDR, in a nutshell?
    >
    > We got lucky with CIDR because even though all default free routers
    > had to be upgraded in a short time, it really wasn't that painful.

    Isn't that an excellent argument against shim6 though?

    In IPv4, something unanticipated occurred by the original developers
    (the need for CIDR), and everyone said "Oh, thank god that all we
    have to do is upgrade DFZ routers." Eventually all hosts got CIDR
    routing, but it didn't break anything if you didn't.

    In IPv6/shim6 what happens if shim6 has an unanticipated bottleneck,
    security issue, or scaleability problem? Everyone, everywhere, has to
    upgrade at some point. This means that upgrade/workaround has to
    backwards compatible indefinitely, since it isn't going to be
    possible to force all the world's servers, desktops and devices to
    upgrade by some flag day.

    If it requires an OS update to add a feature, you can't rely on
    having 90% penetration within YEARS of it being released. After XP
    Service Pack 2 was released, only 24% had upgraded after 9 months.
    According to one of our website's stats, we still see 5% of our users
    on Windows 98, and 13% on Windows 2000. Getting systems not
    controlled by the networking department of an organization upgraded,
    when it's for reasons that are not easily visible to the end user,
    will be extraordinarily difficult to start with. Adding shim6 at all
    to hosts will be one fight. Any upgrades or changes later to add
    features will be another.

    I don't think (many) operators are really dreading having to
    eventually and slowly upgrade their DFZ routers to support 32 bit
    ASNs. It'll require an OS upgrade, probably an upgrade to a few tools
    (netflow parsers, etc), but nothing customer impacting. There will be
    a crossover period where the software will be available but no 32-bit
    ASNs will be visible, until one day some unlucky sap gets AS65536 and
    guinea-pigs the internet. It's a networking problem being solved by
    the guys who run the network, and it can get done in a reasonable
    timeframe, without bothering end users, other departments or touching
    boxes outside the network admin's control.

    In an enterprise environment, you're not talking the DBA of your
    Oracle box into installing service packs, upgrades or new software
    just because you want to use a new routing feature that wasn't around
    when their OS was released. I know of several enterprises still
    running NT 4.0 and Mac OS 9 boxes for some legacy applications. A
    parallel to that is going to still be happening in the next 4-8 years
    when shim6 would have to prove itself. There are going to be
    enterprises, end users, database servers, and embedded devices that
    have IPv6 support because they shipped with it (XP, Vista, OS X,
    Solaris, etc), but don't have shim6 support. The services either get
    an expensive upgrade or lose out on multihoming.

    The real "injustice" about this is that it's creating two classes of
    organizations on the internet. One that's meets the guidelines to get
    PI space, multihomes with BGP, and can run their whole network
    (including shim6less legacy devices) with full redundancy, even when
    talking to shim6 unaware clients. Another(most likely smaller) that
    can't meet the rules to get PI space, is forced to spend money
    upgrading hardware and software to shim6 compatible solution or face
    a lower reliability than their bigger competitors.

    Someone earlier brought up that a move to shim6, or not being able to
    get PI space was similar to the move to name based vhosting(HTTP/1.1
    shared IP hosting). It is, somewhat. It was developed to allow
    hosting companies to preserve address space, instead of assigning one
    IP address per hostname. (Again, however, this could be done slowly,
    without forcing end users to do anything.) ARIN's policy is that you
    should use name based hosting wherever possible. However, if you're
    not using name based hosting(blowing through many IPs that could be
    consolidated if you didn't), all that's asked is that you justify why
    you can't/won't do it that way on your application for PI space. If
    IPv6 PI space worked the same way - If you could justify why shim6
    isn't sufficient for your network, and receive PI space... I'd have
    zero objections to anything shim6 wanted to do. Let those who want to
    use it use it, and let those who can't do what they need to do use
    the existing alternatives. People aren't going to frivolously pay the
    yearly fees for an ASN and address space unless they truly believe
    they need it, and it would completely level the playing field. Small
    businesses won't have an unfair disadvantage to their larger
    competitors who get PI space. Let shim6 (or whatever takes its place
    for IPv6 multihoming) prove itself and seem like a more attractive
    solution than paying for PI space, and you have a winner.

    No matter how much you think shim6 is the way to do it, you're not
    going to have willing users of it unless it's just as good as what
    they're doing now. Unless we start now working on getting people
    moved to IPv6, the pain of running out of IPv4 before IPv6 has
    reached critical mass is going to be much much worse than a long term
    problem of IPv6 route size. The question of IPv6 migration and IPv6
    route size are *two different problems*. Solve them independently or
    neither will get solved. We can't try to force our views of how the
    internet should work on networks when we've already got a fight on
    our hands just convincing them to deploy IPv6 at all. Nothing at all
    precludes allowing people to start deploying multihomed IPv6 networks
    using the traditional system, and presenting alternatives when
    they've proven themselves. If shim6 truly is the perfect match for
    people who need to multihome, new networks will deploy it natively,
    and small companies will accept it as a way to stop paying a yearly
    fee for PI/ASN allocations. If you're not so sure that shim6 meets
    the "it's good enough that people will use it willingly" goal, it's
    not going to work to mandate its use by policy.

    Right now, shim6 isn't even completed. There are networks who could
    be convinced to start deploying IPv6 today, if they had a multihoming
    solution. Let them do this! The sooner we get people publishing AAAA
    records, the smoother the transition is going to be for everyone. I
    really don't want to see the state of the internet if IPv4 is
    exhausted and IPv6 is still being shot down because of policy debates.

    (Again, my organization already has a /32, I'm not out anything with
    the current policies, if anything I'm helping my competition by
    arguing this point)

    -- Kevin


  • Next message: Kurt Erik Lindqvist: "Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD