Re: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility

[Robin Whittle <rw@firstpr.com.au>]

Short version:   I see many problems which would seem to
                 prevent Six/One Router from being feasible for
                 IPv4.  Some of these are also relevant for IPv6.


Hi Christian,

Here is my initial view of your Six/One Router proposal.

http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router.pdf

I wasn't able to completely follow some of what you wrote, but don't
think that affects this critique.

Slow DFZ handling of packets with option headers = header options

   Maybe you don't need option headers if you do a 1:1 mapping
   of the end-user address range in each ISP's address space,
   but that approach won't be acceptable in IPv4 due to the
   large amount of address space it chews.

   Last year, Bill Herrin proposed a system involving option
   headers, which I critiqued here:

     http://psg.com/lists/rrg/2007/msg00344.html

   I recall that the consensus view was that this would never
   be practical due to most (all? or at least some, and therefore
   too many) DFZ routers do not handle any packet with an
   option header at their normal rate.  They handle the packet
   via a slow CPU process.

   So I think that this is one reason your system can't be
   practical for IPv4.

   Maybe IPv6 option headers are not such a problem for DFZ
   routers.  Can anyone confirm this?


Packets are bigger with option headers

   Adding an option header leads to the PTMUD and Fragmentation
   woes which a map-encap scheme needs to handle.  See:

     http://tools.ietf.org/html/draft-templin-seal-03
     http://www.firstpr.com.au/ip/ivip/pmtud-frag/

   and recent discussions on this list between Fred, Iljitsch,
   me and others.


Modifying the DNS to give different results based on what
kind of network the requester is in  (2.4)

   Even if you knew the IP address of the requester, or the
   IP address of its top level NAT if it was behind one or
   more layers of NAT, you would need a really fancy
   database to decide whether the requester was in an
   upgraded network.  Your suggestion that routers could
   modify outgoing packets from upgraded networks to add
   a flag to DNS queries sounds tricky.

   Every caching nameserver with some requesters being in a
   normal network and some in an upgraded network would
   need to be modified to support two cached answers.
   (I am not sure how often this would occur, and I suppose
   you could have a BCP saying that upgraded networks must
   not use external caching nameservers which were not
   themselves upgraded.)

   Even if you could reliably decide this, and provide
   different answers (via some modified nameserver software)
   I don't see how you could ensure that these different
   answers would not have serious negative consequences for
   some or many applications.


Deep packet inspection and modification

   In section 2.2:

        If no inverse translation is known to take place
        at the remote edge network, Six/One routers
!!      translate addresses throughout an entire packet,
!!      including its payload, to avoid address
        inconsistencies.  This is necessary either when
        the remote edge network is legacy, or when the
        local and remote edge addresses are of different
        IP versions.

   I can't imagine how you could:

      1 - Define an algorithm for achieving these
          modifications for all widely used protocols,
          much less every protocol.

      2 - Devote so much CPU time in the ITR to doing
          this.

      3 - Do it without messing up the applications.

      4 - Do it at all with encrypted or cryptographically
          protected packets.

> Your comments and opinions will be highly welcome.

OK, sorry I see only problems with this.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg