Re: IPv6 routing /48s

From: Michael Sinatra (no email)
Date: Mon Nov 17 2008 - 18:20:56 EST

  • Next message: Joe Abley: "Re: IPv6 routing /48s"

    On 11/17/08 14:46, wrote:

    > ARIN claims they are seeing /48s routed, at least in their route tables. I
    > have seen some new momentum on the allocation of /32's, don't know if that
    > is in response to rules like this?? Would be awefully difficult for our
    > organization to come up with the rationale to need 65K /48s internally to
    > justify a /32.

    You may want to post this issue to the ARIN PPML list (see if you're not already
    subscribed), as that might be a useful venue for discussion as well.

    You're right in noting that this is a catch-22. ARIN and other RIRs are
    now giving out PI /48s, but there is still a notion that /32 is
    considered the maximum routable prefix length. However, UCB sees a lot
    of globally-routed /48s (and /35s, /40s, etc.) in our DFZ routing table.
      (I also see some /48s disaggregated from a /32 and announced in at
    least one non-ARIN region, but I am sure this is happening elsewhere.
    :-( ) So, I do think that /48 is beginning to be the new /32 when it
    comes to prefix filtering, but I can also understand those who want to
    hold to the more strict IPv6 filtering policies.

    I think in the end, we are going to end up generally accepting up to
    /48s. Basically, we're going to break the routing table anyway--the
    number of potential /32s is more than enough to do that, and forcing
    everyone who:

    a. needs to be multi-homed; and
    b. needs more than 1-2 subnets

    to get a /32 has to be a waste, no matter how big the potential address
    space is overall.

    One compromise would be to require that blocks that can be aggregated be
    aggregated, and then allow PI /48s. In theory, this could be enforced a
    number of ways, but I am sure we're all aware of how well that works...


  • Next message: Joe Abley: "Re: IPv6 routing /48s"

    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs

    Powered By FreeBSD   Powered By FreeBSD