Subject: [rrg] RACHH: the host-based solution - prepping the PR team to sell it

From: Robin Whittle <[email-masked]>
Date: Fri, 21 Nov 2008 16:49:01 +1100

Short version:

            I am opposed to any host-based solution to the
            routing and scaling problem - for reasons mentioned
            in recent messages.  Below is a fictitious
            document for a routing scaling solution which
            I hope will remain fictitious:

              RACHH - Routing and Addressing Changes Handled in Hosts

            Folks who want to pursue this approach might like
            to consider how they will convince the vast
            majority of:

               OS programmers                  x,000
               Application programmers        x0,000
               ISPs                           x0,000
               End-users                 x00,000,000

            to spend time and money on implementing the
            host-based scheme (and the shift to IPv6).  Until
            all (or almost all) of these people act to adopt
            the new scheme, we will all remain dependent on
            IPv4 - or IPv6 without a scalable routing.

            None of these people will derive any direct benefit
            from their efforts until virtually everyone all of
            them - including almost all of the end-users - has
            adopted RACHH etc. fully.

            In contrast, with a good router-based core-edge
            separation scheme, such as Ivip, LISP etc, early
            adoptors gain direct and immediate benefits,
            irrespective of how many other people have adopted it,
            in the form of portable, multihomable, address space
            at lower costs and without BGP involvement than would
            otherwise be possible.

            Skip to the end - Q32 - for a summary.

Assuming for the moment we decide on a host-based solution, here's a
rough draft of how we might want to bring a public relations company
team up to speed with the challenges of developing a successful campaign.

  - Robin

Team,

Here is our first draft of the key elements of the RACHH campaign - a
brief pep-talk followed by a longer FAQ.  As you can see, we have
drawn a blank at certain points - so we look forward to your creative
suggestions!

{Main announcement / pep-talk}

RACHH - The Internet is Changing for the Better
-----------------------------------------------

  The Internet has grown from being a small research network in the
  1980s to today's global digital network - with billions of users
  depending on it daily for their personal and business
  communications.

  To ensure the Net continues to function reliably, as more and
  more people use it more and more intensively, we will need to
  change the way the Internet works.  The I**F has determined that
  in the next few years, all Internet users will need to upgrade
  the operating systems and application programs on all their
  Internet-connected computers to a new standard of performance:

    RACHH - Routing and Addressing Changes Handled in Hosts

  "Host" is the name for an Internet connected computer, such as
  a desktop computer, cellphone or server.

  We will also need to change our Internet connections to
  a RACHH-compatible service.  This will happen automatically
  as ISPs adopt the new system, but this will often require
  a new DSL or cable modem - or a new cellphone.

  RACHH application programs will perform just like they do
  now.  Once the transition is complete, all Internet activities
  will be as easy as they are now, and some may be easier.

  Best of all, the Net will have a secure and robust future
  for decades to come -  serving us all reliably as we use it for
  voice, video and many other purposes, as well as for Web-surfing,
  IM and email.

{Team: the FAQ is where it gets tricky.  How can we shorten this and
 make people happy with the first few answers, rather than asking
 more and more questions?}

The RACHH FAQ
-------------

 Q1   What is the I**F?

  A     The I**F designs many of the Internet protocols and works
        with other bodies to coordinate IP addresses and the Domain
        Name System (DNS).  Anyone can join the IETF and participate
        in devising new protocols.

 Q2   What is an "Internet protocol"?

  A     A clearly specified set of rules by which two or more
        Internet connected computers can communicate.  For instance
        the HTTP protocol is used by browsers to request pages from
        web servers.  A DSL modem uses several protocols to set up
        the Internet connection with your ISP and to carry the data
        back and forth over the phone line.

 Q3   Who else creates these protocols?

  A     Many companies and individuals create protocols in addition
        to the I**F's - such as protocols for instant messenger
        programs, games, streaming sound and video, peer-to-peer file
        sharing.

 Q4   Can the I**F force anyone to change their software?  If not,
      why should I take any notice of them?

  A     The I**F doesn't control the Internet - no one organisation
        does.  The Internet is made up of the ISPs and end-users who
        connect together to form the global network.  However, the
        basic protocols and addressing system which makes all this
        work have been devised and is administered by the I**F and
        associated organisations.

        The I**F can't force anyone to use the Internet or not, or
        to change how they use it.

        {Team: we need some help on the next para.}

        If ISPs and end-users do not follow the I**F's advice to
        change to the new RACHH Internet, then the Internet will
        become progressively more expensive to run and less reliable.
        Furthermore, more and more end-users who need "multihoming" -
        a reliable connection via two or more ISPs - will continue
        to be unable to obtain this.

 Q5   So the I**F is telling my ISP, all other ISPs, me and
      all other users that we need to change our operating systems,
      probably our modems and change to new RACHH-compatible
      versions of all the programs we use, in order that the
      Internet can keep functioning?

  A     Yes.  The I**F has determined that this is the best solution
        to the scaling problems of the Internet.

 Q6   Why doesn't the I**F change the Internet so it keeps working
      without me or my ISP having to spend money and fuss around
      with complex technical things?   I have enough trouble keeping
      my computer working and safe from viruses as it is!

  A
        {Team??  This is where we need your expertise.  All our
         answers to this are highly technical and will just
         bamboozle most users.}

 Q7  What are the Internet's "scaling problems"?

  A     The first and best-known problem is that the currently
        widely used Internet (IPv4) does not have enough IP
        addresses to cope with the growing number of people
        using it.  There are about 3.7 billion IP addresses,
        and supplies of fresh space - like farmland to be
        turned into suburbs - have dried up.  Although
        only a fraction of these addresses are actually used
        the current approaches to utilising IPv4 addresses
        can't do much better.  So we need another Internet
        to replace the IPv4 Internet - the IPv6 Internet.

        The IPv6 Internet has about 200 billion, billion,
        billion, billion IP addresses.

        The other problem is "the routing scaling problem".
        It concerns the "routers" in the core of the Internet -
        whether it is IPv4 or IPv6.  These are like post-office
        sorting rooms - sending packets out one link or another,
        depending on each packet's destination IP address.

        Many end-user networks, from universities and
        corporations to small offices and home users want or
        need highly reliable connections, and to be able to
        choose another ISP without having to change all the IP
        addresses of the computers and other devices in their
        networks.

        Without RACHH (or without major changes to the routing
        system which the I**F has decided against), the only way
        each such end-user network can multihome their network is
        by all the hundreds of thousands of routers in the "core" of
        the Net having to know about that network, and how it
        connects to the Net via one ISP or another.  This
        information can change from moment-to-moment, and
        collectively the burden of all this information and updates
        about these connections is too much for the core routers.

        Unless we do something - and the I**F has decided that
        RACHH is the best approach - the routers would need to
        be more and more expensive and  the stability of the
        entire Internet is threatened by the volume and complexity
        of this information.

        These routers are purchased and operated by ISPs, so the
        cost of running the core of the Internet is borne by
        all Internet users.

 Q8  OK - I understand the address shortage problem, but how
     bad is it really?  We have already had knowledgeable people
     crying wolf over Y2K - and I have been reading about
     the IPv4 address shortage and the need for IPv6 since
     about then.  Yet the Internet still seems to work and many
     big companies are planning much more intensive uses for it,
     such as downloading entire DVD's worth of video for a few
     dollars.

     Doesn't the Internet work fine now?  Can't everyone use IP
     addresses more efficiently?  Can't we share IP addresses?
     I can connect as many PCs as I like to my DSL modem and
     they all work fine -  so what is the problem?

  A
        {Team - we are working on the answers to these questions.}

 Q9  Waddya mean the "IPv4 Internet" and the "IPv6 Internet"???

  A     All Internet users today use the IPv4 Internet, though
        a few also use the IPv6 Internet too.  IPv6 was devised
        in the mid-1990s and has been available since then, but
        has not been adopted by most users, mainly because it
        doesn't provide access to anything which cannot already
        be accessed via IPv4.

        The IPv4 and IPv6 Internets are two separate networks,
        even though they can run together over the same routers
        and links.  For instance both IPv4 and IPv6 packets can be
        sent along a DSL link at the same time, and computers with
        suitable operating  systems and applications can work with
        both types of packet at the same time.

        To operate on either Internet, the computer needs one
        or more IP addresses within the address space of that
        Internet.  Due largely to the IPv4 address shortage, each
        DSL customer gets one IP address and special Network Address
        Translation (NAT) software in the DSL modem creates a private
        address space for all the connected PCs.  The NAT software
        and translates the source and destination addresses of
        packets going to and from the rest of the Internet so all the
        packets from the local computers go out with their
        destination address being the one IP address.

        The NAT software keeps a track of this is (usually) able to
        figure out which local computer to send a packet to, when
        response packets arrive from the Net.  This means the local
        computers cannot be seen from the outside world - so no
        external computer can initiate a session with them.  (There
        is a way around this, with the NAT software providing
        a direct "port" to the outside world, so that a
        peer-to-peer program, for instance, can accept
        communications initiated by such programs on other
        computers all over the world.)

        IPv6 has so much address space that there is no need
        for NAT - though it is possible that some people may
        use it for security reasons.  NAT is a problem for many
        applications, because it is difficult or impossible for
        computers on private addresses to communicate with other
        computers on private addresses.  There are techniques
        to help with this, but they don't work very well.

        There is no way of sending a packet from an IPv4 address
        to an IPv6 address or vice-versa.  IPv4 packets only have
        32 bits for the destination address and IPv6 addresses are
        128 bits long.

        A single host computer, such as a web server, can have
        both an IPv4 and an IPv6 address - so it is available on
        both the IPv4 and the IPv6 Internet, but these are
        still two separate Internets.  Some protocols can be
        made to work between computers which are not on the same
        Internets - such as the email protocols and a few others.
        Apart from that, IPv4 and IPv6 are two separate Internets.

Q10  So what is the RACHH Internet?

  A     RACHH is the IPv6 Internet, with new capabilities built
        into the operating systems and application programs
        of all connected computers.

        When all, or almost all, users are using RACHH exclusively
        then there will be no problem with address shortages (since
        all RACHH users will be using IPv6) and there will be no
        routing scaling problem, because the RACHH capabilities in
        each "host" computer (each end-user's computer) means the
        routing system can continue to operate as it does today,
        but without having to be concerned with large numbers of
        end-user networks having their own address space.  This
        means the routing system only needs to know about ISP
        networks - which is practical and desirable.

Q11  So the I**F has decided that it is better to upgrade all
     the Internet's computers - all their operating systems
     and their applications - rather than alter the routing
     system?

  A     Yes.

Q12  What if only a tenth, a half or nine tenths of ISPs and
     end-users adopt RACHH?  Won't there still be a scaling
     problem and IPv4 address shortages?  Won't all end-users
     and ISPs need to maintain IPv4 connections and applications
     to keep in touch with the end-users who haven't upgraded
     yet?

  A     If a large majority of ISPs and end-users convert to
        RACHH, then the routing scaling problem and address
        shortage problems will be greatly diminished.  However
        they will not be diminished to any meaningful extent
        if half or less of the ISPs and end-users adopt RACHH.

Q14  By upgrading my Internet service, my operating system and
     my applications to RACHH, will I be able to do anything,
     or access any service, website etc. which I can't access
     already?

  A     No.

Q13  How will my RACHH upgraded computer work with computers
     which are not upgraded?

  A     Operating systems and applications which are upgraded
        to RACHH work fine communicating with other hosts
        which are still using IPv4 - or IPv6 without RACHH.

        However, in order for many of these programs to work
        with those non-upgraded hosts, you will still need
        an IPv4 address and service from your ISP.  Also,
        those applications which assume stable IP addresses
        will need to be upgraded to work with RACHH.  This
        will sometimes means that their protocols will need
        to be changed, so the RACHH mode of operation will
        not be compatible with the pre-RACHH mode.  (The
        pre-RACHH mode will generally be IPv4 only, and
        RACHH mode is purely IPv6 - a similar problem would
        occur simply due to making the application work
        only from IPv6.)

        If you are using your RACHH-upgraded computer on an
        end-user network which is multihomed (using two or
        more ISPs for real-time switching and continued
        session connectivity if one ISP fails) then the
        multihoming will only work for sessions with other
        computers which are also upgraded to RACHH and
        where the session is with an application program
        there which is also upgraded to RACHH.

Q14  So - assuming everyone needs to maintain an Internet service
     which gives them full connectivity to all other users'
     computers - no-one can do without their IPv4 service until
     almost everyone has RACHH, or at least IPv6?

  A     That is correct.

Q15  It has taken me ten minutes to read and understand this
     FAQ so far.  Why should I keep reading?  Why should I be
     the first one to adopt RACHH, IPv6 etc.  Wouldn't it
     be easier and more prudent to wait until most other people
     have adopted it before I do so?

  A
        {Team??}

Q16  What about old applications, old games, etc. which only
     work for IPv4 and are not being maintained?  Likewise,
     I have printers and Wi-Fi gear which only works with
     IPv4.

  A     Those old applications can't be upgraded.  They will
        still work with a RACHH-upgraded operating system, but
        you will need an IPv4 connection to use them.

        Since the RACHH upgraded applications works only over
        IPv6, you will need new Wi-Fi gear if it does not
        already support IPv6.  IPv6 compatible Wi-Fi gear itself
        does not need to be upgraded to handle RACHH traffic,
        but its management interface software should, ideally,
        be RACHH compatible.

Q17  Where is a list of major end-users, universities, corporations
     etc. - or people like me in my home or SOHO setting - who have
     upgraded their systems properly to RACHH.

  A
       {Team - this won't be possible at first.}

Q18  Where are the RACHH compatible operating systems and
     applications?  I have never heard of them?

  A
       {Team - this won't be possible at first either.  We
        need to convince all the operating system suppliers
        and at least some of the major application suppliers
        to adopt RACHH before we can try to convince end-users
        to adopt it - though to some extent RACHH adoption will
        occur via automatic updates and the installation of
        new operating systems and applications.  However, in order
        to do this, we need to show the programmers we have a
        credible campaign to get end-users to recognise and adopt
        RACHH-upgraded software.}

Q19  So worldwide adoption of IPv6 alone is sufficient to solve
     the IPv4 address shortage, but RACHH is required on top of
     this to solve the routing scaling problem too?

  A     Yes.

Q20  Is it an essential part of RACHH's solution to the routing
     scaling problem that no end-user host can have a stable IP
     address - and that multihoming must be done by each host having
     two or more IP addresses from two or more ISPs?

  A     Yes.

Q21  Wasn't the big attraction of IPv6 that everyone could have
     their own IP address space, because there was so much
     available?

  A    Not really - IPv6 was never intended to provide this, because
       it has been known since the early 1990s that the routing
       system in its form then (and as we are maintaining it now
       and into the future) could not scale to so many end-user
       networks having their own PI address space.

Q22  OK - but didn't the RIRs all decide in 2007 and 2008 to give
     end-user networks PI IPv6 space if they asked for it?
     (Not that many took up the offer...)

  A    Yes, because hardly anyone was adopting it and this was
       seen as the only way of making any progress away from
       IPv4 dependence.  There was no scalable routing solution
       then - although SHIM6 was promised for many years.

       Now, once most networks are using RACHH, there won't
       be any need for those IPv6 PI assignments.

Q23  Isn't RACHH like SHIM6 - which no-one really wanted?

  A    SHIM6 didn't require a new API or rewritten apps.

       RACHH does, and when applications are rewritten,
       including to avoid all assumptions about stability
       of IP addresses, the system will really work.

       Like SHIM6, RACHH is a host-based solution to
       multihoming, for IPv6 only, in which benefits only
       accrue to adoptors when their host is communicating
       with another upgraded host.

Q24  I am a network operator.  How am I supposed to keep control
     of my routers, servers etc. when they are on shifting
     sands of having two or more sets of addresses, one for each
     upstream ISP, and I need to add or delete one of these
     sets of addresses?

  A    Put your routers on stable private addresses and use the
       tools the I**F is developing.  See the answer to Q29
       regarding Access Control Lists.

Q25  I am a network operator.  With current BGP-based mulithoming
     the network itself is untouched - all the hosts have their
     IP addresses remaining stable.  I pull some router levers
     to switch from one upstream ISP to another - or program the
     router to do this automatically when needed.

     I don't need to know or care about how many hosts are in my
     network, or what OS or applications they are running.

     With RACHH, how can I know all hosts in my network are RACHH
     capable - such as if someone plugs in a laptop, or uses it
     a laptop or some VoIP handset with the corporate WLAN?

  A    RACHH will only work as expected for hosts which fully
       implement RACHH.

  {Team: the rest of the FAQ is for programmers, not the general
   public.  We are working on this section ourselves, but if
   you have any suggestions......  especially regarding Q31 & Q32.}

Q25  I am an application developer.  Are you saying that I need
     to rewrite my entire application to work with two networking
     APIs?

  A     Yes.  It will probably be best to select at runtime whether
        your app uses the RACHH or the old API, according to
        whether the OS has a RACHH API.

        The RACHH API enables you to do most things you currently
        do in IPv4 or IPv6.  You could use both APIs at the same
        time - for instance the old API for IPv4 hosts and the
        RACHH API for all IPv6 hosts.

Q26  OK - that sounds nutty, but let me just check:

     1 - The app needs to work fine when the RACHH API is not
         available - to IPv4 hosts and, if it is running on an
         IPv6 host (which it isn't at present, since it assumes
         IPv4 and I haven't ported it yet), to IPv6 hosts and to
         IPv6 hosts with RACHH OSes and apps.

     2 - The app needs to work fine with the RACHH API instead
         of the current one, which involves a completely different
         set of calls, new ways of thinking about IP addresses
         etc. when the app is dealing with a mixture of other
         computers, on IPv4 and on IPv6 with and without RACHH.

     This sounds like a debugging and user-support nightmare.

     I may also need to fundamentally redesign my protocol, which
     means it will be impossible to retain backward compatibility
     with pre-RACHH IPv6 versions of my software.  Compatibility
     isn't possible anyway between IPv4 and IPv6, which is a major
     reason why I haven't tried to rewrite it to run on IPv6
     already.

 A      Yes, you will need to completely re-engineer how your
        app works if any part of it is concerned with IP
        addresses.  In RACHH, you only use hostnames, and the
        OS handles the rest.  However, as noted below (Q29),
        to the extent that your app contains its own ACK
        systems, you will need the app to tell the OS if it
        looks like a packet has not been acknowledged.

        Also, the RACHH version of your app can never use IP
        addresses in referrals.

Q27  So everything depends on DNS?  A new kind of DNS where
     the hostname query typically returns multiple IP addresses
     for the OS to use, with a list of priorities and the OS
     does its own reachability testing and probing of alternative
     IP addresses if it looks like sending one or more packets to
     the currently preferred IP address did not produce a response?

  A     Yes, everything depends on DNS and the RACHH OS functions -
        except of course the DNS itself, which will remain rooted
        with a handful of fixed IP addresses.  IP addresses can
        be expressed as hostnames so your app can still send
        packets to explicit addresses - but you generally won't
        want to do this, because that is the old sort of programming
        which can't be supported by RACHH's host-based multihoming.

Q28  What about caching times?  How can the DNS operate so as
     to stop me having to check every ten seconds, if I need
     ten second multihoming recovery time?

  A    The RACHH OS does all the reachability testing.  It needs
       to sense whether sending a packet to an IP address really
       worked.  Sometimes, it will receive an ICMP message if
       that address was unreachable.  But to be more robust,
       your app needs to tell the OS when it suspects a packet
       was not received successfully, so the OS should try to
       send it again.  This won't work at all if your app uses
       UDP and the protocol has no ACK system.  TCP will be
       fine - the OS will detect lack of ACKs and will attempt
       another address.

       However, you your app and its protocols will need to
       be rewritten if they ever pass IP addresses between
       hosts, or store IP addresses for later use.  To ensure
       your app works with RACHH host-based multihoming,
       you must always identify each host by its hostname alone.
       This means that all hosts you communicate with will need
       their own hostname in the DNS.

       It also means your app will need to cope with a host
       on private address space, which has its own hostname
       there, but which accesses the Net via NAT (ideally this
       would not be the case, but it may happen), and so
       the packets from this host actually arrive from an
       IP address which is different from any of the
       addresses returned when the DNS is queried with the other
       host's hostname.  We are still working on how the RACHH OS
       and applications will handle this.

Q29  I am an application developer and/or someone who is involved
     in mobile devices, including ultra-low-power battery operated
     wireless embedded devices.  I understand RACHH involves hosts
     sending hostnames to each others, initially at least, and
     in a much greater real-time dependence on the DNS.

     Hostnames are variable length fields - and are potentially
     very long.  Also, there are some complexities with non-ASCII
     domain names, with Punycode etc. which sound like a nightmare
     to program.

     It looks tricky to implement an ACL with RACHH.  Wouldn't
     the device need to do regular DNS lookups to find the current
     IP addresses of the allowed (or excluded) hosts and networks?

     Thus, an ACL entry would involve the text name of a host
     or network, with some mechanism to look this up in DNS,
     convert it into an IP address or subnet address and prefix
     length.  Then there would need to be frequent, repetitive,
     DNS lookups, and/or some interaction with the RACHH code if it
     decides the host or network has a new address now . . .

     Also, with RACHH multihoming, a host might have any number
     of potential IP addresses and a network could have any
     number of prefixes and prefix length pairs.  This sounds
     like it would be onerous to program.  Variable numbers of
     IP addresses, constant DNS checking to update them according
     to the primary definition of the ACL entry, which is in the
     form of a text string, of arbitrary length, in ASCII or in
     some other format.

     I also understand that a failure to receive an ACK (at the TCP
     or application layer) will need to be treated as evidence that
     the remote host is now unreachable by the current IP address.
     I understand this will involve the OS in sending the same
     packet to another IP address, complete with hostname and
     probably some nonce or other crypto stuff (won't that make
     the packet longer, raising MTU and PMTUD problems?), so the
     session can continue.  I am not sure how the applications at
     both ends are supposed to cope with these retransmissions and
     potentially duplicate receptions.  Will there be an option
     for not resending time-sensitive packets?

     Whatever the answer to these questions, doesn't this mean
     that:

     1 - There will be more traffic on the mobile link, taking
         more time and chewing more battery power?

     2 - A more complex stack will be required, with more
         storage and perhaps crypto stuff?

     3 - The flaky, slow and long-latency nature of wireless will
         slow down DNS requests and responses and contribute to
         false alarms about the other host not being reachable,
         particularly when my protocol involves previously
         lightweight UDP packets?

 A      Yes, all this is true.

        UDP can't be lightweight in any host-based multihoming
        system such as RACHH while still retaining current
        assumptions about IP address stability.

Q30  How does RACHH work with a hosting company changing one
     or more of the IP addresses a web-server works on?  That
     server may be mentioned in the DNSes of several dozen
     customers.  How can those customers securely allow this
     particular entry in their DNS to be updated by the
     hosting company at any time?

  A     This is administratively and technically complex,
        but possible.

Q31  I am an operating system developer and I like to think I know
     something about the Internet's routing system.  Why did the I**F
     decide to keep the current routing system architecture untouched
     and instead create a bunch of host-based protocols to be added
     to the responsibilities of hosts?

  A    Because we decided firstly that the scaling problem couldn't
       be solved with any upgrade to BGP, or any single alternative
       to BGP - even if a way could be found to introduce an
       alternative without disruption.

       Secondly, we decided on a host-based solution because:

       1 - We didn't like the idea of adding a new architectural
           structure to the interdomain routing, such as was
           proposed in the core-edge separation schemes of LISP, APT,
           Ivip, TRRP and Six/One Router.

       2 - We thought that the current assumptions that a host could
           assume its IP address was stable, and that the hosts it
           is communicating with would likewise have stable addresses
           - at least for the current session - was unreasonable.
           This assumption developed over the years in an ad-hoc
           fashion when there was no scaling problem.  We decided
           it was a mistake to consider any host (apart from the root
           DNS servers) should have a stable IP address.

       3 - It fits well with the tradition of "smart host - dumb
           network".

Q32  So how is this any different from:

     *  The I**F being averse to sullying the supposedly "pure"
        architecture of the routing system,

     *  regarding end-users as being uppity for thinking they
        could have their own IP addresses (despite the vast
        supply in IPv6),

     *  therefore deciding to punt the responsibility for
        handling long-term and short-term changes in the
        routing system from the routing system itself, all
        the way to the host operating system - with:

        #  consequently increased network related management
           traffic to and from each host,

        #  a greater number of potential combinations of
           OS, app and circumstances at each end, making
           for a greater number of potential failure conditions
           and - at least from the network manager's point of
           view - greater difficulty monitoring and debugging
           multihoming etc.,

        #  more storage in the host etc

        #  the need to develop a new API and to force all
           applications to be rewritten for the API, and to be
           redesigned to the extent that they previously made
           any direct use of IP addresses, or assumed that IP
           addresses resulting from conventional DNS lookups
           could be regarded as stable?

  A
      {Team??}

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2008 14:04:38 +1300

> From: Robin Whittle <[email-masked]>
> Date: Nov 21, 2008 6:49 PM

>             IPv4 - or IPv6 without a scalable routing.

It's become fashionable to assert that host based solutions
are undeployable. I would like to recall that the model for
rolling out shim6 is very clear - in MS-talk it's called
"Updates are ready for your computer" - since *all* it requires
is an IP stack upgrade. There are absolutely no changes for upper
layers (except maybe a small tweak for SCTP code) and absolutely
no changes for routers or ISPs. Of course, it's true that shim6
is not much use until a critical mass of users have installed
that update, and it doesn't include TE features for ISPs.
But the deployment model is o(OS programmers) in terms of
significant cost.

It's clear that once you ask for action by application
programmers or non-routine action by end users, the costs
become unthinkable.

    Brian

---

From: Robin Whittle <[email-masked]>
Date: Mon, 24 Nov 2008 13:20:39 +1100

Hi Brian,

> But the deployment model is o(OS programmers) in terms of

This only works for that subset of devices for which the operating
system is actively maintained and upgraded, for which the programmers
invest in adding SHIM6, for which automatic updates are possible and
for which the end-user of each device enables such automatic updates.

This rules out older desktop and server operating systems, printers,
networking gear (Wi-Fi etc.), NAS boxes, probably lots of hand-held
devices which only have expensive mobile links to the Net and are not
so suitable for automatic OS updates etc.

I don't see how this is a viable method of achieving the critical
mass required for multihoming based on SHIM6 to become useful.
Multihoming 10%, 50% or probably anything less than 95% of traffic
does not strike me as useful.  Multihoming is only of value when it
works for essentially all traffic.

For this reason, I think it would be impossible to successfully
introduce a host-based approach to multihoming - except perhaps over
a period of 15 years or so.  There are so many devices which would
never be upgraded that it would take years - maybe a decade or more -
before they were thrown away and replaced by something modern with
the new system built in, that the people who did install the system
on all their hosts had 95% or more of their traffic properly
multihomed with the new system.

Until that level is reached, there are only costs and risks in
installing the new system.  There is no substantial benefit until
95%, 99% or whatever of the other hosts in the world have been
upgraded too.

> programmers or non-routine action by end users, the costs

Yes.  That is why I think trying to introduce a host-based scalable
routing solution is a non-starter.  SHIM6 is not regarded as a
solution, and the only potentially viable host-based solutions
require changes to applications too, so they all use a new
hostname-based API.

I think that LISP, APT, Ivip, TRRP and Six/One Router are all based
on the belief that a host-based solution is not the way to go.

There are other, more fundamental, problems with a host-based
scalable routing solution   - even if there was no problem
introducing it.  I will write more about these in another message.

 - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 Nov 2008 21:54:34 -0500

If we take the view that nothing can change, then we will be correct. 
Nothing will change.
At that point, the best possible outcome is NAT66, which is not much of 
a "best" in my book.
LISP, and similar schemes, will provide better NAT support for limited 
cases.

But we will not have an architecture.  We will have an assemeblage of parts.
It will keep working.  But it will make various things harder and 
harder.  Referrals are only the first thing to fall victim to such an 
assemblage.

There are ways to change more things, with transition strategies that 
enable communication in the intervening cases.  (Saying that we must 
change the host, without dealing with the intermediate / mixed cases 
would indeed be a non-starter.)

But, as long as we assume we can not do so, then we won't.

Yours,
Joel Halpern

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 24 Nov 2008 09:20:00 +0100

Hi Robin,

I think multi-homing in edge networks MUST support legacy hosts.
Adding ISP uplinks to single-homed edge networks can be very beneficial.
Taking an existing ISP uplink out of service would need more attention, but
don't say this is impossible or not cost-effective. Let's say: it depends.
More important: it can be decided site by site.

So I do not agree on:
> introduce a host-based approach to multihoming

Teco.

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]] Namens Robin
> Whittle
> Verzonden: maandag 24 november 2008 3:21
> Aan: RRG
> Onderwerp: Re: [rrg] RACHH: the host-based solution - prepping the PR
> team to sell it
> 
> Hi Brian,
> 
> You wrote:
>

---

From: Robin Whittle <[email-masked]>
Date: Mon, 24 Nov 2008 21:28:01 +1100

Hi Teco,

>> introduce a host-based approach to multihoming

in http://www.irtf.org/pipermail/rrg/2008-November/000215.html

> I think multi-homing in edge networks MUST support legacy hosts.

I understand this as: if an edge network adopts any kind of scalable
routing solution, that the solution must provide 100% support for
multihoming for all incoming packets, including those sent by hosts
in non-upgraded networks (AKA, for a host-based solution, upgraded
hosts).  Otherwise, with less than 100% of traffic responding to the
multihoming system, it wouldn't be enough use to anybody to make them
want to install it.

If this is what you meant, I agree with you.

> Adding ISP uplinks to single-homed edge networks can be very beneficial.

But it requires some kind of scheme to make them useful.  Currently,
the only way to multihome like this is to get PI space and advertise
it into the DFZ through one ISP or the other.  As more and more
end-user networks do this, so we have the routing scaling problem.

> More important: it can be decided site by site.

I haven't been able to understand this clearly, or why you think it a
host-based routing scaling solution could pass either set of
critiques I (and others) have made:

1 - It would be impossible to deploy it widely enough (in any
    reasonable time frame) that there were such a proportion of
    all hosts (such as 95%, 99% or whatever) that the resulting
    multihoming would actually be useful to anyone who deployed it -
    this is because a host-based solution only works when both
    hosts are upgraded.  This is especially so if the scheme involves
    rewriting applications, as well as host stacks.

    As Brian Carpenter wrote recently:

2 - As I wrote here:

     Fundamental objections to a host-based scalable routing solution
     http://www.irtf.org/pipermail/rrg/2008-November/000233.html

    It would be undesirable to push this functionality out to hosts,
    compared to handling it with some new architectural structures
    in the network (that is, the routing and addressing system in
    the core of the Net and in ISP and end-user networks).

  - Robin

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 24 Nov 2008 16:39:35 +0100

Hi Robin,

> end-user networks do this, so we have the routing scaling problem.
 
Multi-homing with PA is possible. See RFC3704 section 4 on suggested
solutions. My BRDP Based Routing proposal is an enhancement, it eliminates
careful planning and configuration and the need for tunnels.

>     the core of the Net and in ISP and end-user networks).
 
I prefer a step-by-step approach. 

The first step would upgrade edge networks for multi-homing, this enables
multi-homing for hosts that can make use of it. 

In a second step, hosts are updated. It depends on the gain for users how
fast a transition takes place. Keep in mind that many end-user hosts use
dynamic addresses already (single address, IPv4, lots of NAT). Day-to-day
renumbering is no problem at all.

Upgrading server farms requires special attention. I would not say servers
MUST have static unique addresses, there are examples of hosted servers
based on DNS names. For those, multi-homing is not that difficult to
implement.

I think the subject line has some negative judgment. And I would call it the
edge-based solution.
Keep in mind that I do not prefer edge-based over core-based. I think they
are orthogonal.

Teco.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Nov 2008 08:35:39 -0800

>-----Original Message-----
>From: Teco Boot [mailto:[email-masked]]
>Sent: Monday, November 24, 2008 7:40 AM
>To: 'Robin Whittle'; 'RRG'
>Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR
team tosell it
>Keep in mind that I do not prefer edge-based over core-based. I think
they

Where I run into difficulties is when "edge-based" solutions
are extended all the way into the core such that end sites are
locked into a provider-aggregated "matrix".

Proper balance therefore depends on careful determination of
where does "the edge" end and "the core" begin...

Fred
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Nov 2008 17:44:56 +0100

On 24 nov 2008, at 3:20, Robin Whittle wrote:

>> "Updates are ready for your computer"

> for which the end-user of each device enables such automatic updates.

Right.

If, along with that, we can keep legacy IPv4 applications running,  
which should be possible because there are only some 14M /24s in IPv4,  
we should be in good shape. No need to keep the latest stuff in the  
non-latest OSes or the non-latest stuff in the latest OSes running,  
except for that old IPv4 stuff that will be around for a good while.

> does not strike me as useful.

Hm, I'd rather redownload 5 out of 10 files when my ISP craps out than  
10 out of 10. Partial deployment for multihoming is still useful.

> 95%, 99% or whatever of the other hosts in the world have been

This would be true for the scalability issue.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 24 Nov 2008 17:14:03 -0800

>From: Templin, Fred L 
>Where I run into difficulties is when "edge-based" 
>solutions are extended all the way into the core 
>such that end sites are locked into a provider-aggregated "matrix".

>Proper balance therefore depends on careful 
>determination of where does "the edge" end and "the core" begin...

I'm not tracking you here, Fred. Your recent I-D's (RANGER, VET, SEAL),
when combined, naturally suggest recursive deployments. In recursion,
the concepts "edge" and "core" are local to a specific recursive
instance.

For example, map-and-encaps solutions can be implemented in a recursive
manner. In such a system, edge and core are concepts which are local to
a specific recursive instance. Given this, a provider-aggregated matrix
could only be visible if it occurred within the context of a specific
recursive instance -- it would be transparent to any other recursive
instance, right?

---

From: Robin Whittle <[email-masked]>
Date: Tue, 25 Nov 2008 15:04:33 +1100

Hi Iljitsch,

You wrote:

> If, along with that, we can keep legacy IPv4 applications running, which
> should be possible because there are only some 14M /24s in IPv4, we
> should be in good shape. No need to keep the latest stuff in the

I don't understand this clearly.  IPv4 isn't "legacy" and won't be
until after most of the world's billion or so Internet users and
their ISPs have been convinced to change over to IPv6, which for a
long time will be a network where only a subset of other hosts can be
reached on.   Even if IPv4 applications are in the minority, and
still need to run, I don't understand your reference to 14 million
/24 prefixes.

> 10 out of 10. Partial deployment for multihoming is still useful.

Yes, but I would say that for any substantial organisation, running
servers or having a bunch of desktop users or both, that they are not
going to invest in some new technology, more complexity, new
addressing arrangements perhaps and a second ISP if the new
multihoming scheme is only going to work for half their traffic.

I think they would need a much higher figure - such as 90%, 99% or
something like - this before the multihoming could be regarded as
substantial enough to justify the investment.

> This would be true for the scalability issue.

Yes, but Ivip with its OITRDs (Open ITRs in the DFZ) and LISP with
its PTRs (Proxy Tunnel Routers) can provide multihoming for 100% of
traffic, no matter how few other networks are upgraded.

  - Robin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2008 13:06:46 +0100

On 25 nov 2008, at 5:04, Robin Whittle wrote:

> until

Semantics. IPv4 is nearly 30 years old and severely behind the times.  
Even its replacement, IPv6, isn't very new. The fact that many people  
are running IPv4 doesn't change this.

> Even if IPv4 applications are in the minority, and

Current practice is that you need a /24 to gain entry into the world  
wide routing system. We have 221 usable /8s * 65536 = a maximum IPv4  
routing table of 14483456 entries. That is of course 50 times as big  
as what we have today, but at least there is some kind of reasonable  
limitation here.

> multihoming scheme is only going to work for half their traffic.

We have less than 25000 multihomers world wide today, so apparently  
most people are happy with even a single ISP, and would presumably be  
even happier with some form of multihoming even if it doesn't provide  
the full benefits of the "real" thing with PI addresing, especially if  
there are no additional costs beyond a second connection.
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 25 Nov 2008 10:17:44 -0800

Eric,

>From: Fleischman, Eric
>Sent: Monday, November 24, 2008 5:14 PM
>To: Templin, Fred L; Teco Boot; Robin Whittle; RRG
>Subject: RE: [rrg] RACHH: the host-based solution - prepping the PR
teamtosell it
>I'm not tracking you here, Fred. Your recent I-D's (RANGER, VET, SEAL),
when combined, naturally
>suggest recursive deployments. In recursion, the concepts "edge" and
"core" are local to a specific
>recursive instance.

Yes, I think this is correct. The recursion can be applied
from the core and continuing infinitely out to "the edges"
however far removed from the core they may be. And, I agree
with the observation that edge/core are local to their
specific recursive instance.

>For example, map-and-encaps solutions can be implemented in a recursive
manner. In such a system,
>edge and core are concepts which are local to a specific recursive
instance. Given this, a provider-
>aggregated matrix could only be visible if it occurred within the
context of a specific recursive
>instance -- it would be transparent to any other recursive instance,
right?

Yes; the aggregated matrix would only be visible within a
particular recursive instance and, beyond that, it could
(and possibly should) be all provider-independent addressing.
Where I really have trouble is when some suggest that the
aggregated matrix penetrates all the way into the core.
That would be a total domination scenario for the ISPs,
and in that lies madness...

Fred