[RRG] TRRP-Via - option header vs. encapsulation

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

On 24 August, in message:

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

Bill Herrin wrote, in part:

>> Robin Whittle wrote:
>> They all have similar problems with tunneling overhead,
>> fragmentation, breaking traceroute and Path MTU Discovery.
>
> Hi Robin,
>
> What about something like this:
>
>  http://bill.herrin.us/network/trrp-via.html

I have only a partial understanding of your goals here, and what
your proposed mechanism involves.  I have almost no prior
understanding of loose source routing, and found this explanation
helpful:

  http://www.synacklabs.net/OOB/LSR.html

I understand that (for IPv4) your proposal involves the ITR adding
an option header to it which functions similar to loose source
routing -  rather than adding a second outer header (encapsulation,
to tunnel the packet).

I understand your proposal is like loose source routing, but with a
different option number (0x9E = 158) and with the following
important differences:

      Loose Source Routing          Via IP option

1     Destination address           Destination address
      is changed to be that         remains that of the
      of the intermediate           original packet - the
      router.                       destination host.

2     The address of final          The address of the intermediate
      destination host is           router (ETR) is specified in the
      specified in the option       option header.
      header.

3     All routers en-route to       All routers en-route to the ETR
      the intermediate router       must find the option header,
      need only look at the         and use the address there rather
      ordinary destination          than the packet's DA - for
                                    routing.

I think the third point means that all DFZ routers (and maybe some
routers in ISP networks, depending on where the ITRs and ETRs are)
would need to be upgraded before your proposal could be used.  If
so, then I think the proposal is impractical, since this violates a
key requirement for incremental deployment.

I understand this proposal involves a lower additional number of
bytes, which is good, but I think that even a single byte extra
raises the whole ugly problem of fragmentation (at least in IPv4).

I don't know enough about ICMP messages to know whether the other
desired benefit would really occur - enabling Path MTU Discovery
between the ITR and ETR, with the sending host getting the messages
and adjusting its packet lengths accordingly.

Does the router generating the ICMP message back to the sending host
include just the basic IPv4 header and "8 bytes following", or is it
supposed to include the option parts of the header too?  If the
latter, the sending host will not recognise the option parts, since
the ITR added them - which would break PMTUD.

The MTU reported by that router (RFC 1191) would not help, since if
the sending host used it, the ITR's addition of the option header
would still cause the resulting packet to be too long.  You mention
this in your message.

It seems that PMTUD is not reliable anyway, depending on how deep in
the ISP etc. networks the ITR and ETR are located due (for instance)
to there being generally less filtering of ICMP messages in the DFZ
compared to inside ISP or end-user networks.

I want the ITRs and ETRs to be located potentially quite deep in the
networks, to provide flexibility and therefore large numbers of them
- to reduce the load on any one ITR or ETR.  ITRFH involves the
sending host (not behind NAT, but perhaps done in the NAT device,
which is not, in the case of DSL routers, a hardware based router)
doing a caching ITR function.

  - 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