Subject: Last Call: Internet Protocol, Version 6 (IPv6) Specification to Draft Standard

From: The IESG <[email-masked]>
Date: Tue, 05 May 1998 06:55:47 -0400

The IESG has received a request from the IPNG Working Group to consider the following as Draft Standards:

o Internet Protocol, Version 6 (IPv6) Specification 
  <draft-ietf-ipngwg-ipv6-spec-v2-01.txt> replacing RFC 1883, currently
  a Proposed Standard.

o Internet Control Message Protocol (ICMPv6) for the Internet Protocol
  Version 6 (IPv6) Specification <draft-ietf-ipngwg-icmp-v2-00.txt>
  replacing RFC 1885, currently a Proposed Standard

o Path MTU Discovery for IP version 6 <rfc1981>, currently a Proposed
  Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[email-masked] or [email-masked] mailing lists by May 19, 1998.

Files can be obtained via 
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-01.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v2-00.txt
ftp://ftp.isi.edu/in-notes/rfc1981.txt

Implemenation Reports for all three can be found at

	http://www.ietf.org/IESG/implementation.html

---

From: Bill Fink <[email-masked]>
Date: Wed, 13 May 1998 17:41:15 -0400 (EDT)

>   replacing RFC 1885, currently a Proposed Standard

The following paragraph in section 3.3 was removed from RFC 1885, and
needs to be reinstated to make it clear that the interface on which packet
forwarding fails when generating an ICMP Time Exceeded error message SHOULD
be the interface on which the packet was received:

   "The router sending an ICMPv6 Time Exceeded message with Code 0 SHOULD
   consider the receiving interface of the packet as the interface on
   which the packet forwarding failed in following rule (d) for
   selecting the Source Address of the message."

Note there was also a typo in the above quoted portion of RFC 1885.
The reference to rule (d) should actually be a reference to rule (c).

This is required because many IPv4 implementations actually do this
incorrectly, owing to the ambiguity of the phrase "the interface on
which the packet forwarding failed" in rule (c) of section 2.2, and
this can lead to an arbitrary use of either the receiving or next
outgoing interface for the source address of the ICMP error packet.
This in turn can reduce the effectiveness of the traceroute diagnostic
tool.  I had originally argued that the SHOULD should be a MUST to
eliminate any doubt, but at least the SHOULD text needs to be reinstated
to remove the current ambiguity in the new ID.

						-Bill

---

From: Steve Deering <[email-masked]>
Date: Tue, 16 Jun 1998 10:26:13 -0700

This is a response to the comments by Masataka Ohta on the IESG's Last Call
for advancing the base IPv6 spec to Draft Standard.

At 11:15 AM -0700 5/13/98, Masataka Ohta wrote:
> I'm agaist the promotion because:
>
> 	1) The change on minimal MTU is significant to worth it be
> 	a proposed standard again.
>       ...
>
> 1) is a procedural problem, which may be technically ignored.

I would argue that the change of minimum MTU should not be considered a
reason to delay advancement to Draft Standard, because:

	(a) It is not a change of the protocol (i.e., an addition or
	    deletion of a feature or behavior), but rather just an
	    adjustment of one of the protocol's parameters.

	    (If you wish to argue that the specification of a "large"
	    minimum MTU is a change, well that change was present in the
	    Proposed Standard version -- which replaced IPv4's 68-octet
	    min MTU with 576 -- so the use of a "large" min MTU has already
	    passed the number-of-implementations and passage-of-time
	    requirements to advance to Draft.)

	(b) The decision to make the change of min MTU from 576 to 1280,
	    the documentation of that change, and the implementation of
	    that change in most (probably all) of the many IPv6 host and
	    router implementations occurred more than six months ago, with
	    no reported interoperability problems or any other kinds of
	    problems.  Thus the necessary multiple-implementations and
	    passage-of-time requirements of the IETF have in fact been met,
	    and insisting on another six month delay is very unlikely
	    to uncover problems that would not already have surfaced.

> 	2) The current specification does not limit the length
> 	of the header.
>
> ... 2) is a fatal problem.

No, it is not a fatal problem, it is a feature, an improvement that makes
IPv6 more flexible than IPv4.

> However, there seems to be a persistent confusion in IPNG WG that the
> problem could have been solved by fragmentation.

I don't remember anyone -- prior to your Last Call comments -- claiming
on the ipngwg mailing list or in an IPng WG meeting that the lack of a
fixed bound on header(s) size was a problem for IPv6.  Therefore, suggesting
that the WG suffers from "persistent confusion" about the solution to this
newly alleged problem seems unjustified to me.

> The problem 2) is that, even though there are some non-TCP
> protocols such as DNS over UDP which needs a standard on smallest
> payload size, which is not given by IPv6.
>
> With IPv4, reassembly buffer is assured to be 576 byte long
> and headers are, at most, 64 byte long, which means 512 bytes
> of payload data can be safely transmitted betweeen IPv4 networks
> and a sender. To make the network more active, however, even
> though the size of the reassembly buffer of IPv6

The final sentence in the paragraph above is incomplete, so I cannot
understand your description of the alleged problem.

> Worse, the kernel may insert some header unknown to the applications.

That's an implementation problem, not a protocol problem.  If a kernel
is capable of inserting headers (other than Fragment headers) into outgoing
packets, it must also have some way of telling the upper-layer protocols
how many bytes of headers are being inserted, so that the upper layers can
take that into account when choosing how many bytes of payload to send.
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.

If a node's kernel has been configured to insert so many header bytes into
all outgoing packets that specific upper-layer protocols won't work on that
node because their minimum payload size requirements cannot be satisfied
within the reassembly buffer size of the destination(s), then you have the
choice of not running those upper-layer protocols on that node or fixing
the kernel configuration.

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.

Steve

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Jun 98 1:11:20 JST

Steve;

> 	    requirements to advance to Draft.)

The change from 576 to 1280 is significant at least because it
may make PMTU discovery totally unnecessary, which is a protocol
change.

> 	    to uncover problems that would not already have surfaced.

Then, can we measure the actual path MTUs used?

Or, you can argue that the operational experiences we have collected
so far are not real ones. :-)

The operational experiences of proposed standard protocols are
required also to remove unnecessary features.

> fixed bound on header(s) size was a problem for IPv6.

I pointed it out at the WG last call and there has been a confusion that
the issue can be solved by fragmentation.

> understand your description of the alleged problem.

Oops, sorry. The problem is that the increase size of the reassembly
buffer of IPv6 does not assure that we can trasmit 512 byte of payload.

Again, the issue can not be solved by forcing an insertion of the
fragmentation header.

> That's an implementation problem, not a protocol problem.

It is a protocol problem.

See below.

> If a kernel

Wrong.

Upper layer protocol specifications are written independent of
kernels, which makes the problem a protocol problem.

To assist the design of the upper layer protocols, it is necessary
to specify within the standard, how many bytes are left for the
payload.

> required for Path MTU Discovery) would be a natural place to include this

You are the live example of the persistent confusion.

This is NOT the MTU problem. This is the problem of reassmebly
buffer size.

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.

> the kernel configuration.

Wether some node runs some protocol or not is an operational, not protocol,
problem, of course.

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.

Moreover, a kernel may be asked to insert some header invisible
to the application, for example, for mobility.

> that do *not* have a particular payload size constraint.

???

Can you show me some example?

Even TCP needs some minimum assured payload length because it need
a fixed size header in every packet.

							Masataka Ohta

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 18 Jun 1998 13:30:41 -0500

> may make PMTU discovery totally unnecessary, which is a protocol

It does not eliminate the usefulness of PMTU discovery.  By itself
that doesn't quite contradict your statement, but add to it the
presumption that systems will use the full MTU of their local link
when possible and you are refuted.

Your other complaint, about the protocol spec. not limiting the
headers the kernel can insert, is just another, and more unlikely,
example of a problem that could occur in IPv4 but which, in practice,
does not.  Some routers block fragments with small offset values to
avoid certain attacks.  If a link exists with the minimum allowed MTU
value of 68 bytes, then a node which inserts the maximum IPv4 options
cannot communicate through that link and that router.

> a fixed size header in every packet.

1. It's not fixed in size.
2. It must appear in every *reassembled* packet.

TCP could work (although very badly!) with just one available byte
per packet.

Masataka, could you please state your goal?  If IPv6 were recycled at
PS, what would you change?  Are you aware that your first objection
(mn. allowed MTU increase) diminishes the significance of your second
objection (unlimited extension headers)?
______________________________________________________________________________
Matt Crawford                    [email-masked]                     Fermilab
"A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment,
thoroughly smash them with a hammer or an ax, and scatter the pieces."

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Jun 98 11:06:09 JST

Matt;

> It does not eliminate the usefulness of PMTU discovery.

It does not elminate PMTUD but make it almost uselss.

> By itself

"when possible"? What do you mean?

Systems should use the full MTU of their local link
when possible and meaningful.

We may use link local MTU when the destination is located link local,
for example.

> cannot communicate through that link and that router.

Matt, you are another live example of the persistent misunderstanding.

It is not a fragmentation issue.

> TCP could work (although very badly!) with just one available byte

TCP may work with just one available byte per fragmented packet,
as long as the payload length of the reassembled packet is not less
than 21 bytes.

However, when the payload of a unfragmented or reassembled packet is
10 byte long, which is smaller than TCP header, TCP does not work.

> Masataka, could you please state your goal?

To make IPv6 work.

							Masataka Ohta

---

From: Steve Deering <[email-masked]>
Date: Fri, 19 Jun 1998 02:11:00 -0700

> may make PMTU discovery totally unnecessary, which is a protocol

Masataka,

PMTU Discovery has never been "totally necessary", regardless of the
minumum MTU.  It is *beneficial* to perform PMTU Discovery whether
the minimum MTU is 68, 576 or 1280.  *How* beneficial it is depends on
the actual MTUs encountered in the Internet.  Currently there are many paths
with MTU of 1500, which is larger than 1280, and there are some paths with
MTUs significantly larger than 1500.  Within the lifetime of IPv6, the
Internet may well change to have very many paths with MTUs significantly
larger than 1280.  Therefore, changing the minimum MTU to 1280 does not
eliminate the desirability of performing PMTU Discovery, and we have not
changed the protocol as a consequence of increasing the minimum MTU to
1280.

> Then, can we measure the actual path MTUs used?

That sounds like a big job with very little likelihood of any payoff, but
if you think that by doing such measurements you can prove some unknown and
unanticipated failure introduced by the increase of minimum MTU, you are
welcome to try.

> required also to remove unnecessary features.

If you are trying to argue that Path MTU Discovery should be removed from
IPv6, then please just say so directly.

I presume that features will be added to and removed from IPv6 over its
lifetime as conditions and requirements change and as more experience is
acquired, just as has been the case with IPv4.  But unless you can
show that Path MTU Discovery as currently specified for IPv6 has a
serious interoperability problem, I don't think your displeasure with
the presence of that feature should be sufficient grounds to delay the
advancement of the protocol along the standards track.

> I pointed it out at the WG last call...

But as I said, prior to your message, no one raised the issue.

> ...and there has been a confusion that the issue can be solved by
> fragmentation.

In the same message that raised the issue for the first time, you accused
the WG of "persistent confusion" about the issue.  Since the WG had never
discussed it, you had no basis for such an accusation.

> buffer of IPv6 does not assure that we can trasmit 512 byte of payload.

That's correct, the protocol made no such assurance when the min MTU was
576, nor when it changed to 1280.

The assurance is obtained operationally: it would stupid to configure a
node to insert more than 768 bytes of header into *every* outgoing packet,
not only because it would prevent the use of protocols of the sort you
are worried about, but also because it would be a terribly inefficient
use of bandwidth.  However, that does not mean it is stupid to allow the
use of more than 768 bytes of header in *some* packets (preferably
infrequent ones).

> Again, the issue can not be solved by forcing an insertion of the

I never said it could.

> kernels, which makes the problem a protocol problem.

The notion of "kernels" is OS-specific, and indeed has no place in a
protocol spec.  However, protocols designed to operate over IP must
take into account the needs and constraints of IP.  There is a tradeoff
beween payload size and IP-layer header size (and, ideally, path MTU),
and that tradeoff may differ for different upper-layer protocols and in
different environments.  The more adaptable the upper-layer protocols and
the more adaptable the IP layer, the better.  Communication between the
layers is essential to enable such adaptivity.

> to specify within the standard, how many bytes are left for the

If you *really* need to wire a single payload size number into your upper-
layer protocol, go ahead and use 1024.  That would allow up to 476 bytes of
headers within the required reassembly buffer size, which had better be
more than enough for most packets (that's 32% header overhead -- if we need
more than that, datagrams are doomed).  But that's an operational
recommendation, not a protocol requirement.

> This is NOT the MTU problem. This is the problem of reassmebly

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).

> which means even TCP do not work, regardless of whether the packet

Correct.  That's a good reason not to put 1490 bytes of header in a TCP
packet.

> 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.

> 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.

> 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.)

Steve