[RRG] SEAL, PMTUD, IPv6 header bloat, header compression

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

Hi Fred,

in two messages in the "Is ISATAP a practical solution" you
mentioned some things to do with the problem of Path MTU Discovery
for ITRs to ETRs, fragmentation of packets etc. - and your SEAL
proposal which intended to help with these.

  http://tools.ietf.org/html/draft-templin-seal-04  (new today)

I haven't read SEAL in detail yet.

I wrote, in:

  http://psg.com/lists/rrg/2008/msg01112.html

    I have a dimmer view of IPv6 than many IETF folks.  I think 64
    bit addresses would have been better.  With 128, there are 32
    bytes of address in every packet - which seems like overkill
    when there are millions of people sending two-way streams of 50
    VoIP packets a second with only 20 bytes of payload.  However
    there are creative uses of the extra bits, such as Six/One.

    This address burden gets worse with any map-encap tunneling
    header, so I am keen to keep Ivip encapsulation as minimal as
    possible: IP-in-IP.  LISP involves a LISP header and therefore a
    UDP header as well.  I am also keen to avoid anything like a
    SEAL header, at least on the shorter packets in any map-encap
    tunnel.

and:

    The one thing I could imagine making IPv4 completely unworkable
    would be every cellphone on the planet having its own mobile
    public IP address, which I think could be done with the
    map-encap approach to mobility.  Since there are 3.3 billion
    such devices now, IPv4 could never do that.  But then think of
    those bloated IPv6 addresses chewing up bandwidth on cell-phone
    radio links carrying streams of VoIP packets.


However when I wrote this, I was also thinking of the map-encap
headers with at least two sets of IPv6 source and destination
address (inner payload packet and the encapsulation header) going
over the mobile link - which would be horrible.  This isn't right.
In the TTR-based model of mobility with map-encap schemes, the
mobile node (MN) has its own (potentially proprietary) 2-way tunnel
to the nearby TTR.  Apart from the basic IPv6 header, the lengthy
additional header stuff to do with the map-encap scheme I was
discussing in the first two paragraphs above only travels in the
ITR->ETR part of the path, and the TTR plays the role of ETR.  So
map-encap headers, SEAL headers etc. don't need to go to the MN.

You responded to the third paragraph above:

> Again, header compression has been proposed.

OK - a suitably sophisticated header compression on the radio link
would be able to find the repetitive parts of streams of VoIP
packets etc. and compress their IPv6 headers, and perhaps their UDP
are RTP headers significantly.

Header compression could also be done in the MN <--> TTR protocol.

>> I am also keen to avoid anything like a SEAL header, at least
>> on the shorter packets in any map-encap tunnel.
>
> Including the SEAL header on large packets and omitting
> it on smalls is certainly an idea to be taken seriously
> and not to be dismissed w/o further consideration. However,
> reasons we might not want to do that include:
>
>  1) multiple encapsulation formats on the same link; could
>     confuse both tunnel endpoints and middleboxes
>
>  2) omission of SEAL header reduces identification to
>     only 16 bits; may not be sufficient for duplicate
>     packet and/or off-link attack detection
>
> What are your thoughts on this?

I will have to read the SEAL material before commenting further, but
I think it is really important to avoid extra headers unless they
are really needed - especially for the vast streams for small
packets such as VoIP.


> BTW, the idea of extending the IPv4 ID to 32 bits in a
> manner similar to the way SEAL does it is not new. The
> earliest proposal to do this (which I came across after
> publishing SEAL) was from Steve Deering on the mtudwg
> mailing list in Feb. 1990:
>
>   http://ipvlx.org/mtudwg-log
>
> but I wouldn't be surprised if there were still
> earlier proposals. The primary difference between what
> SEAL is doing and what Steve articulated was that Steve
> proposed a new IPv4 option, whereas SEAL proposes a new
> IPv4 protocol.

New IPv4 header options are not practical since DFZ routers won't
handle them quickly (or perhaps at all?).  A map-encap system
definitely needs a solution to the PMTUD and fragmentation problems.
   I am hoping to do it in Ivip without any extra headers in the
traffic packets, and with a new protocol for ITRs probing PMTU to
ETRs.  As our discussions last year showed, this is a really
difficult business.  I won't be updating my plans, currently
summarised at:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

until I have read your SEAL proposal and given it a lot more thought.

  - 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