Subject: Last Call: IP Version 6 over PPP to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 31 Dec 1997 11:30:17 -0500

The IESG has received a request from the IPNG Working Group to consider
IP Version 6 over PPP <draft-ietf-ipngwg-ipv6-over-ppp-04.txt> as a
Proposed Standard. This document will replace RFC2023 which will be
reclassified as Historic.

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 January 14, 1998.

Files can be obtained via
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-04.txt

---

From: Stephen Casner <[email-masked]>
Date: Wed, 31 Dec 1997 13:07:01 -0800 (Pacific Standard Time)

> reclassified as Historic.

I have no comment on the changes made from RFC2023 to the new draft,
but there is an additional change that I believe should be made.

The IPv6-Compression-Protocol option lists one "current value":

           004f                    IPv6 Header Compression

There is no reference listed for this PPP protocol number assignment
either in the most recent "Assigned Numbers" RFC nor in the file
ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers, but my
understanding is that this assignment corresponds to a proposed header
compression protocol specified in an internet-draft that expired some
time ago without being published as an RFC.

Meanwhile, a different IP header compression protocol designed for use
with both IPv6 and IPv4 has been developed in the IPNG WG and is
specified in draft-degermark-ipv6-hc-05.txt.  Last Call was also
requested on this draft (on November 23), though the Last Call notice
has not been posted yet.

Last Call was also requested (two days ago) on a companion i-d
draft-engan-ip-compress-02.txt that defines extensions to the
IP[v6]-Compression-Protocol options in the PPP Control Protocols for
IPv4 and IPv6 [RFC1332, RFC2023] to handle negotiation of additional
parameters for the new compression protocol.  This draft also suggests
to IANA the assignment of value 0061 (as one of a set of assignments)
for this header compression protocol.

Given that RFC2023 is being updated now as well, all the right
up-to-date references should be made.

In draft-ietf-ipngwg-ipv6-over-ppp-04.txt:

  - The IPNG WG should decide whether the 004f assignment should be
    deprecated and how it should be listed (or not) in this draft.

  - The value 0061 (assuming IANA proceeds with that assignment)
    should be listed for the new IP header compression protocol.

  - There should be references to the RFC's that the two drafts
    draft-degermark-ipv6-hc-05.txt and draft-engan-ip-compress-02.txt
    are published as, assuming Last Call on them is approved.

In draft-engan-ip-compress-02.txt:

  - References to RFC2023 should be updated by the RFC Editor to be
    the new RFC that draft-ietf-ipngwg-ipv6-over-ppp-04.txt becomes.

In other words, I suggest that draft-ietf-ipngwg-ipv6-over-ppp-04.txt
be updated and then processed with the package of the other two drafts
and a fourth related draft I didn't mention here.
							-- Steve

---

From: Dimitry Haskin <[email-masked]>
Date: Wed, 31 Dec 1997 17:28:56 -0500

>requested on this draft (on November 23), though the Last Call notice

Yes, I'll add a reference to this draft to the IPv6/PPP spec.

>    should be listed for the new IP header compression protocol.

Why is a new number needed if there is already one (004f) allocated by IANA?
A reference to an appropriate document can be simply added to the
ppp-numbers document.

>and a fourth related draft I didn't mention here.
Dimitry

---

From: Stephen Casner <[email-masked]>
Date: Wed, 31 Dec 1997 14:47:28 -0800 (Pacific Standard Time)

> A reference to an appropriate document can be simply added to the

Reasonable question.  We suggested re-use of 004f when we presented
the need for number assigments to the PPPEXT working group, but there
was some resistance to relinquishing the assignment of 004f to the
older IP6 header compression protocol.  In addition, multiple number
assignments were needed because the new scheme is a framework in which
compression of multiple different protocol headers may be done, so
there are multiple packet formats.  The allocation at 0061 allows the
assignments to be contiguous, which is convenient (but not required).

							-- Steve