Re: Shim6 vs PI addressing

[Owen DeLong <owen () delong com>]

--On March 2, 2006 11:31:51 AM +0100 Jeroen Massar <jeroen () unfix org> wrote:

> On Thu, 2006-03-02 at 02:21 -0800, Owen DeLong wrote:
> > > > Personally, I think a better solution is to stop overloading IDR
> > > > meaning onto IP addresses and use ASNs for IDR and prefixes for
> > > > intradomain routing only.
> > >
> > > Did you notice that 32bit ASN's are coming and that IPv4 addresses are
> > > 32bits? :) Which effectively means that we are going to route IPv6 with
> > > an IPv4 address space. Or when one would use the 32bit ASN for IPv4:
> > > routing a 32bit address space with an 32bit routing ID. The mere
> > > difference
> > Yes, I am well aware of 32bit ASNs.  However, some things to consider:
> >
> > 1.   Just because ASNs are 32 bits doesn't mean we'll instantly
> >      issue all 4 billion of them.  The reality is that we probably
> >      only need about 18 bits to express all the ASNs well need for
> >      the life of IPv6, but, 32 is the next convenient size and there's
> >      really no benefit to going with less than 32.
>
> True. If we would take the 170k routes that are in BGP at the moment
> then a 18bits address space is enough to give every route a dedicated
> ASN. The issue is that there are way more people who might want to
> multihome than that, just take the number of businesses on this planet,
> add some future growth and we'll end up using the 24th bit too quite
> quickly. Which is, according to some people who do routing code, no
> problem at all. Like shim6, see first then believe.
>
> > 2.   In my current thinking on how to achieve ASN based IDR, we
> >      would not need ASNs for every organization that multihomes,
> >      only for each organization that provides transit.  This
> >      would greatly reduce some of the current and future demand
> >      for ASNs.
>
> Paper/draft/description/website? :)
Paper: Haven't gotten that far yet.
Draft: Haven't gotten that far yet.
Description: See below
Website: Haven't gotten that far yet.

Description:  This is still knocking around in my head so far.  I've
discussed
and described it to a few folks, but, there are lots of details to work out
yet.

So, this will require a fair amount of imagination on your part, and, it
will
require letting go of a lot of assumptions built on the current dogma and
paradigm.  This is in many ways a completely different paradigm for
interdomain
routing.

Basically, internet routers would come in three flavors:

        1.      Intradomain Routers -- Routers which have a default route
                and limited or no detailed knowledge of topology beyond
                the local ASN.

        2.      DFZ Edge Routers -- Routers which participate in the IDR
                process ("full BGP feeds") which have adjacencies with
                Intradomain Routers.

        3.      DFZ Core Routers -- Routers which participate in IDR as
                in 2 above, but, which do not have any adjacencies with
                routers from category 1 above.

In the long run, routers in category 2 and 3 would only carry prefix
information for routes terminating in the local AS.  For all exterior
routes and peering sessions, only AS PATH data would be exchanged,
without any prefix information. (In the interim, BGP would be unchanged
and routing table bloat would continue to be an issue, but, the routing
process could change on a router-by-router basis without requiring a
"flag day" conversion).

Routers in category 2 would insert an IPv6 extension header of type 53
with a new subtype (yet to be defined, probably 1) which would contain
the Destination ASN for the packet.  The lookup of Prefix->ASN mapping
would be accomplished by a process similar to DNS (See Route Resolvers
below).

Routers in category 2 and 3 would forward packets by the following ruleset:

                Is extension header present?

                Yes: Is it my local ASN?
(A)                     Yes: -- Prefix route available?
                                Yes: Route packet by IGP
                                No: Perform exterior resolution and rewrite
                                        ASN header if possible.  Otherwise,
                                        drop packet. (see loop prevention
                                        below for details)
(B)                     No: -- Forward based on ASPATH data to reach AS

                No: Resolve ASN -- Local?
                        Yes: -- Continue process from (A) above
                        No: -- Insert Extension header and continue
                                from (B) above.
                        Unresolvable: -- Drop packet, send Unreachable no route

Route Resolver:

        Two new RR types and one new hierarchy would need to be added to DNS.

        The RR types would be AS and SIG, which would provide AS data similar
        to MX records and Cryptographic Signature data which could be used
        to trace the delegation of authority for the prefix back to IANA.

        The new hierarchy would be something like in-as.inet. and would
        be used to map IPv6 prefixes to NS/SIG records until the most
        specific match was found, yielding an AS/SIG record pairs.

        The  signature of NS records would contain the public key of the
        next level delegated authority so as to make it possible to validate
        that the records it returns had to be signed by the appropriate
        private key.

Loop Prevention:

        The reason the ASN redirect is necessary is to support clients who
        multihome without their own ASN.  They would advertise records for
        each upstream ASN.  There would be no global knowledge of which
        ASN was or was not workable at a given time until DNS changed (probably
        a manual process).

        In order to prevent loops in this redirect process, it would be
        necessary to have a second extension header (probably another
        subtype of type 53) which would contain a list of destination
        AS already visited.  Each router performing AS Redirect would not
        consider any AS already in this list and would add the AS
        which it removed on to the list before forwarding.

OK... That's it in a nutshell.  Yes, there are lots of details that still
aren't worked out, but, I think it is a feasible process for IDR and it
would
allow virtually unlimited PI addressing with routing table growth tied
to the number of transit ASNs instead of to the number of prefixes or
multihomed leaf sites.


> > True, but, until recently, I was being told that ARIN insisted that the
> > 200 "customers" had to be non-related third parties.  E.g. Chevron
> > couldn't use all their different business units as 200 customers of
> > Chevron Corporate IT.  It appears based on some recent allocations that
> > they may have relaxed that stance.
>
> It might have been that ARIN was a bit stricter, the other RIR's though
> have never given any real problems as far as I know. The few ones that I
> heared of that couldn't get it, either didn't try or didn't want to
> "lie" about their plans.
Nonetheless, this was a showstopper for a number of enterprises I know
in North America.

Owen



-- 
If it wasn't crypto-signed, it probably didn't come from me.

Attachment: _bin
Description: