Subject: Re: (IPng 5892) Re: Last Call: Internet Protocol, Version 6

From: [email-masked]
Date: Fri, 19 Jun 1998 11:16:30 EDT

In a message dated 6/19/98 5:23:32 AM Eastern Daylight Time, [email-masked]
writes:

> > > Whatever API is used to tell the upper layers about the Path MTU (as
>  > > required for Path MTU Discovery) would be a natural place to include
this
>  > > information.

>  > You are the live example of the persistent confusion.

>  > This is NOT the MTU problem. This is the problem of reassmebly
>  > buffer size.
  
>  I understand that.  The fact that you are confused by my answer does not
>  imply that I am confused. :-)  There is an API needed between IPv6 and the
>  upper layers to support Path MTU Discovery;  I was suggesting extending
>  that API to include other IP length information -- in particular,
>  information about how many bytes of header will be inserted by the IP
layer.
>  For an upper-layer protocol that adapts to Path MTU, that value would be
>  subtracted from the discovered MTU.  For non-adaptive upper-layers, that
>  value would be subtracted from 1280 (if it wished to avoid any chance
>  of fragmentation) or from the reassembly buffer size of the destination
>  (either the minimum value of 1500 or a larger value learned through
>  a protocol exchange).

Is providing IP header length information necessarily meaningful
at this point?  Suppose the destination is group or multicast.
The packet may be transmitted on multiple interfaces with
different amounts of header information transmitted on
each interface.
  
>  > When a header is 1490 byte long, you can use only 10 bytes of payload,
>  > which means even TCP do not work, regardless of whether the packet
>  > is fragmented or not.
  
>  Correct.  That's a good reason not to put 1490 bytes of header in a TCP
>  packet.
  
>  > However, as a protocol issue, the upper layer protocols need a
>  > kernel-independent value on the safe payload length. For the
>  > compatibility to IPv4, the value MUST be not less than 512 bytes long.
  
>  I don't know where you got the 512 number from.  For IPv4, the maximum
>  assured payload size is 576 - 60 = 516.  For applications above the
>  "kernel" (i.e., above the transport layer), the maximum assured payload
>  size is 576 - 60 - 60 = 456 for users of TCP, and 576 - 60 - 8 = 508 for
>  users of UDP.
  
>  > Moreover, a kernel may be asked to insert some header invisible
>  > to the application, for example, for mobility.
  
>  The content of an inserted header may be invisible to the application,
>  but there must be some way for the application to discover its presence
>  and its size.  That is necessary for proper application adaptation to path
>  MTU.  The same header-size discovery mechanism may also be used for
>  applications that do not adapt to path MTU.
  
>  > > Imposing a limit on the number of header bytes in an IPv6 packet would
>  > > unnecessarily limit the capabilities of IPv6 for upper-layer protocols
>  > > that do *not* have a particular payload size constraint.

>  > ???

>  > Can you show me some example?

>  "Signalling" protocols like RSVP need to send infrequent messages to
>  routers along a path or multicast tree.  In IPv6, such signalling could
>  be accomplished with a Hop-by-Hop Options header (to touch every router
>  along a path) or with a Destination Options header preceding a Routing
>  header (to touch specific routers).  It is desirable not to place an
>  artificial constraint on the size of those headers.  (In the extreme case,
>  a packet may carry nothing but IP-layer headers -- i.e., no information
>  for an upper-layer at the packet's destination, which would be indicated by
>  the "No Next Header" next header value in the last IPv6 extension header.)

I have not been giving full attention to this discussion, but I have
the impression that Masataka Ohta is actually asking for a new
parameter to characterize the protocol, a minimum transmit unit
payload size.

Joachim Martillo
<A HREF="http://members.aol.com/Telford001/">Telford Tools, Inc.</A>

---

From: Steve Deering <[email-masked]>
Date: Fri, 19 Jun 1998 08:39:23 -0700

> different amounts of header information transmitted on

A source of an IP multicast packet transmits that packet on one interface
only; it is the routers' responsibility to forward the packet to all
necessary links.  When a router originates a multicast packet, the same
model applies, in that logically the packet is "originated" on one
interface and then "forwarded" to any other interfaces required.
Forwarders are not permitted to insert headers into IPv6 packets.
(If they wish to add information to a packet, they can do so by
encapsulation.)

Steve