Re: shim6 @ NANOG

From: Tony Li (no email)
Date: Sun Mar 05 2006 - 20:26:17 EST

  • Next message: Steven M. Bellovin: "Re: shim6 @ NANOG"

    Stephen Sprunk wrote:

    > Who exactly has been trying to find scalable routing solutions?

    Well, for the last decade or so, there's been a small group of us who
    have been working towards a new routing architecture. Primary
    influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark,
    Atkinson, Fuller, Huston, Rekhter and Meyer. Apologies to any folks
    that feel I've incorrectly included or excluded them. ;-)

    > IPv6 advocates have been pushing a no-PI model for over a decade because
    > that's what ISPs told them to do.

    More accurately, the routing community has been trying to avoid PI
    addressing simply because of the scalability (and thus cost) concerns.

    > When they found end users didn't like
    > that, they went off and developed what has become shim6 as a poor
    > apology. There has never been any significant work done on replacing
    > CIDR with something that scales better.

    More accurately, that work (GSE/8+8) was slapped down politically
    without due technical consideration. Note that replacing CIDR isn't
    exactly the point. The point is to have something that scales. Where
    CIDR can't cope is exactly when we come to multihoming. When
    multihoming was a rare exception, the small number of PI prefixes
    remains tolerable. However, over time, the continued growth in
    multihoming, even solely as a function of the growth of the Internet
    will come to dominate the cost structure of the routing subsystem.

    The only alternative to a PI-like architecture is to provide multihomed
    sites with multiple prefixes, none of which need to be globally
    disseminated. Making this multiple prefix architecture work was the
    charter of the multi6 group. This was constrained in interesting ways,
    as both NAT box solutions were considered politically unacceptable, as
    was changing the core functionality of the v6 stack (i.e., redefining
    the TCP pseudoheader). Given these constraints, it was somewhat
    unsurprising that NAT got pushed into the host.

    From my perspective, we have now explored the dominant quadrants of the
    solution space and various factions have vociferously denounced all
    possible solutions. You'll pardon me if some of us are feeling just a
    tad frustrated.

    > Every such proposal I've seen
    > has been ignored or brushed aside by folks who've been doing CIDR for
    > their entire careers and refuse to even consider that anything else
    > might be better.

    More accurately, the folks that have been CIDR advocates 'for their
    entire careers' are exactly the same folks who have been advocating
    shifting to something else, but have been rejected by other political
    elements when trying to propose actual architectural change. Further,
    those same CIDR advocates have been, and continue to be, in such
    political disfavor that they are effectively powerless anyhow. It
    hardly seems like their rejection could count for much.

    > All this time, energy, and thought spent on shim6 would have been better
    > spent on a scalable IDR solution.

    On that, we can agree. However, my feeling is that fully exploring the
    solution space is an unfortunate necessity before the community is
    willing to accept changes to the fundamental v6 architecture.

    > Luckily, we still have another decade or so to come up with something.

    Unfortunately, that's not entirely true. If the RIR's begin wholesale
    PI assignment, then we start down the road of re-constituting the v4
    routing architecture, locking in additional cost and complexity with
    each PI prefix. All such prefixes will be indefinitely grandfathered,
    so even if something new does come along, we will continue to pay for
    the overhead forever.

    Regards,
    Tony


  • Next message: Steven M. Bellovin: "Re: shim6 @ NANOG"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD