Secure Email Options for Message Privacy

General, Technology

Fairly Secure, Actually

via Creative Commons Search

Many of us had assumed our feeble Gmail passwords were secure enough to keep prying eyes out of our email accounts. But with revelations that the NSA can pretty much demand any email service turn over valuable and private information about our email, more attention has been turning to sources for encrypted secure email services.

So what can you use for secure email now?

 Email is basically not secure. There are steps you can take to protect yourself, through both free and paid services, but the U.S. government has shown its willingness to compel even legendary secure email services like Lavabit–which Edward Snowden used for five years–to shut down. If you’re truly paranoid, here are your options.

Instant Messaging

Instant messaging, often referred to in security circles as “synchronous communication,” is, surprisingly, often more secure than email. The way to go here is with a setup called OTR, or Off The Record Messaging. OTR was set up to provide deniability for metadata, which means that unlike with many less-secure kinds of email, even if somehow you get your hands on a transcript, there’s no way to prove exactly who was communicating. Each individual message is highly encrypted using AES keys, which means that any hacker would have to decrypt each message to get the entire conversation–and decrypting one AES key is a task worthy of a team of hackers. OTR is also fairly easy to use; you can get a plugin for popular chat clients like Adium, Pidgin, and IM+ (the latter costs extra).

Back to Email

But, okay, say you need asynchronous communication, meaning you have to send a message and have the receiver open it at some later point. There are ways to make email really difficult to crack, though the fact that the U.S. has the legal authority to demand metadata throws a real wrench into the whole setup. Still! There are still some for-pay email providers (largely based outside the U.S., now) that use powerful security like OpenPGP and public-key encryption, and which swear they won’t let the man snoop in your data.

Public-key encryption is an underlying idea beneath most secure digital messaging. Each user has two keys: a public key and a private key. These are mathematically related, though it is essentially impossible to figure out the private key from only the public key. Imagine that you have a box. Only you have the key to open it. But you can send this box, unlocked, to anyone, so it’s public, and they can put whatever they want in the box. Then that person locks the box, so now even they can’t get it open. They send the locked box back to you, and you open it with your private key. If you want to respond, you’ve got to do the same with their unlocked box. The major benefit is that you never have to share your key with anyone else.

OpenPGP is software that uses public-key encryption; it’s free to use (hence the “open” part) and is available on a wide variety of platforms. It handles the creation and authentication of keys, among other things. PGP stands for “Pretty Good Privacy,” which isn’t that encouraging, but it’s the most widely used cryptographic standard in the world.

GnuPG: GnuPG is a very popular free implementation of OpenPGP. You can use GPG with one of a variety of front-ends as a plugin for encrypting your emails through your choice of email programs, from Apple Mail to Outlook to Gmail. But they require some setup, and there are paid services that will handle it all for you and which offer advanced features like hidden IP addresses, destruction of files after a period, and offsite storage in friendlier countries. And this is a very popular option for those who can figure out how to use them; it’s the most popular recommendation on this Slashdot thread, for example.

But! Assuming you’re not ready to set up your own email encryption, you want to look for email services that use OpenPGP. Here are some options:

Countermail: Countermail is a paid service which keeps its servers in Sweden. It uses OpenPGP, but also has some advanced options like a hardware USB key, so nobody can even start the email process without inserting a USB drive into the computer. Countermail also does not use any hard drives during the sending of emails–they actually use CDs–so there’s no chance of your IP address being logged anywhere. It’s not cheap, though; you can buy it in packages, the cheapest of which is 24 months for $100.

Bitmessage: Bitmessage is a newish service, created in the style of Bitcoin. It also uses public-key encryption, but when you send an email, it mixes it with all other emails being sent, which makes it pretty much impossible for anyone in the middle to figure out from where the email was sent. They also don’t have any information as to the receiver of the email, so each individual message contains the data from every other message that’s also going through Bitmessage. The receiver’s key, however, only retrieves the message that was intended for his or her inbox. Messages are also not archived; to keep from having a bazillion old emails floating around, being downloaded all the time, messages are deleted after two days. It’s completely decentralized, which might make it the best option for those who fear the government. Who is the government going to issue a request to? There’s nobody in charge!

NeoMailbox: Based in Switzerland, NeoMailbox is a traditional paid service like Countermail. It uses OpenPGP encryption, but also has some nice features, like the option to choose your own domain or use an unlimited amount of disposable email addresses. It also might be the easiest to use; it plugs into lots of existing mail services like Thunderbird, Outlook, and even has an Android app. Depending on how much storage you need, NeoMailbox ranges from $50 a year (1GB) to $110 a year (10GB).

Hushmail: Hushmail is perhaps the best-known alternative to Lavabit and Secret Circle. It’s also available for free, at least for some basic features, which is pretty nice. For free, you get OpenPGP encryption, 25MB of storage, any domain you want, and a nice web-based service. For a little extra you can more storage and your IP address hidden. But Hushmail has been controversial; it’s based in Vancouver, and has previously handed over records when requested by the British Columbia government. Hushmail says it won’t respond to foreign demands, but I’d recommend one of the other services instead, just in case.

Another interesting possibility is Pond, an asynchronous communication service that has its messages expire a week after they’re opened, with no exceptions. It isn’t ready yet, though; its creator says “Dear God, please don’t use Pond for anything real yet.” But it’s promising.

RFC 3156

Research, RFC, Technology

Network Working Group M. Elkins
Request for Comments: 3156 Network Associates, Inc.
Updates: 2015 D. Del Torto
Category: Standards Track CryptoRights Foundation
R. Levien
University of California at Berkeley
T. Roessler
August 2001
MIME Security with OpenPGP

Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the “Internet
Official Protocol Standards” (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

This document describes how the OpenPGP Message Format can be used to
provide privacy and authentication using the Multipurpose Internet
Mail Extensions (MIME) security content types described in RFC 1847.

1. Introduction

Work on integrating PGP (Pretty Good Privacy) with MIME [3]
(including the since withdrawn “application/pgp” content type) prior
to RFC 2015 suffered from a number of problems, the most significant
of which is the inability to recover signed message bodies without
parsing data structures specific to PGP. RFC 2015 makes use of the
elegant solution proposed in RFC 1847, which defines security
multipart formats for MIME. The security multiparts clearly separate
the signed message body from the signature, and have a number of
other desirable properties. This document revises RFC 2015 to adopt
the integration of PGP and MIME to the needs which emerged during the
work on the OpenPGP specification.

This document defines three content types for implementing security
and privacy with OpenPGP: “application/pgp-encrypted”,
“application/pgp-signature” and “application/pgp-keys”.

Elkins, et al. Standards Track [Page 1]

RFC 3156 MIME Security with OpenPGP August 2001

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119.

2. OpenPGP data formats

OpenPGP implementations can generate either ASCII armor (described in
[1]) or 8-bit binary output when encrypting data, generating a
digital signature, or extracting public key data. The ASCII armor
output is the REQUIRED method for data transfer. This allows those
users who do not have the means to interpret the formats described in
this document to be able to extract and use the OpenPGP information
in the message.

When the amount of data to be transmitted requires that it be sent in
many parts, the MIME message/partial mechanism SHOULD be used rather
than the multi-part ASCII armor OpenPGP format.

3. Content-Transfer-Encoding restrictions

Multipart/signed and multipart/encrypted are to be treated by agents
as opaque, meaning that the data is not to be altered in any way [2],
[7]. However, many existing mail gateways will detect if the next
hop does not support MIME or 8-bit data and perform conversion to
either Quoted-Printable or Base64. This presents serious problems
for multipart/signed, in particular, where the signature is
invalidated when such an operation occurs. For this reason all data
signed according to this protocol MUST be constrained to 7 bits (8-
bit data MUST be encoded using either Quoted-Printable or Base64).
Note that this also includes the case where a signed object is also
encrypted (see section 6). This restriction will increase the
likelihood that the signature will be valid upon receipt.

Additionally, implementations MUST make sure that no trailing
whitespace is present after the MIME encoding has been applied.

Note: In most cases, trailing whitespace can either be removed, or
protected by applying an appropriate content-transfer-encoding.
However, special care must be taken when any header lines – either
in MIME entity headers, or in embedded RFC 822 headers – are
present which only consist of whitespace: Such lines must be
removed entirely, since replacing them by empty lines would turn
them into header delimiters, and change the semantics of the
message. The restrictions on whitespace are necessary in order to
make the hash calculated invariant under the text and binary mode
signature mechanisms provided by OpenPGP [1]. Also, they help to
avoid compatibility problems with PGP implementations which
predate the OpenPGP specification.

Elkins, et al. Standards Track [Page 2]

RFC 3156 MIME Security with OpenPGP August 2001

Note: If any line begins with the string “From “, it is strongly
suggested that either the Quoted-Printable or Base64 MIME encoding
be applied. If Quoted-Printable is used, at least one of the
characters in the string should be encoded using the hexadecimal
coding rule. This is because many mail transfer and delivery
agents treat “From ” (the word “from” followed immediately by a
space character) as the start of a new message and thus insert a
right angle-bracket (>) in front of any line beginning with
“From ” to distinguish this case, invalidating the signature.

Data that is ONLY to be encrypted is allowed to contain 8-bit
characters and trailing whitespace and therefore need not undergo the
conversion to a 7bit format, and the stripping of whitespace.

Implementor’s note: It cannot be stressed enough that applications
using this standard follow MIME’s suggestion that you “be
conservative in what you generate, and liberal in what you
accept.” In this particular case it means it would be wise for an
implementation to accept messages with any content-transfer-
encoding, but restrict generation to the 7-bit format required by
this memo. This will allow future compatibility in the event the
Internet SMTP framework becomes 8-bit friendly.

4. OpenPGP encrypted data

Before OpenPGP encryption, the data is written in MIME canonical
format (body and headers).

OpenPGP encrypted data is denoted by the “multipart/encrypted”
content type, described in [2], and MUST have a “protocol” parameter
value of “application/pgp-encrypted”. Note that the value of the
parameter MUST be enclosed in quotes.

The multipart/encrypted MIME body MUST consist of exactly two body
parts, the first with content type “application/pgp-encrypted”. This
body contains the control information. A message complying with this
standard MUST contain a “Version: 1” field in this body. Since the
OpenPGP packet format contains all other information necessary for
decrypting, no other information is required here.

The second MIME body part MUST contain the actual encrypted data. It
MUST be labeled with a content type of “application/octet-stream”.

Example message:

From: Michael Elkins
To: Michael Elkins

Mime-Version: 1.0

Elkins, et al. Standards Track [Page 3]

RFC 3156 MIME Security with OpenPGP August 2001

Content-Type: multipart/encrypted; boundary=foo;
protocol=”application/pgp-encrypted”

–foo
Content-Type: application/pgp-encrypted

Version: 1

–foo
Content-Type: application/octet-stream

—–BEGIN PGP MESSAGE—–
Version: 2.6.2

hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
—–END PGP MESSAGE—–

–foo–

5. OpenPGP signed data

OpenPGP signed messages are denoted by the “multipart/signed” content
type, described in [2], with a “protocol” parameter which MUST have a
value of “application/pgp-signature” (MUST be quoted).

The “micalg” parameter for the “application/pgp-signature” protocol
MUST contain exactly one hash-symbol of the format “pgp-“, where identifies the Message
Integrity Check (MIC) algorithm used to generate the signature.
Hash-symbols are constructed from the text names registered in [1] or
according to the mechanism defined in that document by converting the
text name to lower case and prefixing it with the four characters
“pgp-“.

Currently defined values are “pgp-md5”, “pgp-sha1”, “pgp-ripemd160”,
“pgp-md2”, “pgp-tiger192”, and “pgp-haval-5-160”.

The multipart/signed body MUST consist of exactly two parts. The
first part contains the signed data in MIME canonical format,
including a set of appropriate content headers describing the data.

The second body MUST contain the OpenPGP digital signature. It MUST
be labeled with a content type of “application/pgp-signature”.

Elkins, et al. Standards Track [Page 4]

RFC 3156 MIME Security with OpenPGP August 2001

Note: Implementations can either generate “signatures of a
canonical text document” or “signatures of a binary document”, as
defined in [1]. The restrictions on the signed material put forth
in section 3 and in this section will make sure that the various
MIC algorithm variants specified in [1] and [5] will all produce
the same result.

When the OpenPGP digital signature is generated:

(1) The data to be signed MUST first be converted to its content-
type specific canonical form. For text/plain, this means
conversion to an appropriate character set and conversion of
line endings to the canonical sequence.

(2) An appropriate Content-Transfer-Encoding is then applied; see
section 3. In particular, line endings in the encoded data
MUST use the canonical sequence where appropriate
(note that the canonical line ending may or may not be present
on the last line of encoded data and MUST NOT be included in
the signature if absent).

(3) MIME content headers are then added to the body, each ending
with the canonical sequence.

(4) As described in section 3 of this document, any trailing
whitespace MUST then be removed from the signed material.

(5) As described in [2], the digital signature MUST be calculated
over both the data to be signed and its set of content headers.

(6) The signature MUST be generated detached from the signed data
so that the process does not alter the signed data in any way.

Note: The accepted OpenPGP convention is for signed data to end
with a sequence. Note that the sequence
immediately preceding a MIME boundary delimiter line is considered
to be part of the delimiter in [3], 5.1. Thus, it is not part of
the signed data preceding the delimiter line. An implementation
which elects to adhere to the OpenPGP convention has to make sure
it inserts a pair on the last line of the data to be
signed and transmitted (signed message and transmitted message
MUST be identical).

Example message:

From: Michael Elkins
To: Michael Elkins

Mime-Version: 1.0

Elkins, et al. Standards Track [Page 5]

RFC 3156 MIME Security with OpenPGP August 2001

Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
protocol=”application/pgp-signature”

–bar
& Content-Type: text/plain; charset=iso-8859-1
& Content-Transfer-Encoding: quoted-printable
&
& =A1Hola!
&
& Did you know that talking to yourself is a sign of senility?
&
& It’s generally a good idea to encode lines that begin with
& From=20because some mail transport agents will insert a greater-
& than (>) sign, thus invalidating the signature.
&
& Also, in some cases it might be desirable to encode any =20
& trailing whitespace that occurs on lines in order to ensure =20
& that the message signature is not invalidated when passing =20
& a gateway that modifies such whitespace (like BITNET). =20
&
& me

–bar

Content-Type: application/pgp-signature

—–BEGIN PGP MESSAGE—–
Version: 2.6.2

iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
—–END PGP MESSAGE—–

–bar–

The “&”s in the previous example indicate the portion of the data
over which the signature was calculated.

Upon receipt of a signed message, an application MUST:

(1) Convert line endings to the canonical sequence before
the signature can be verified. This is necessary since the
local MTA may have converted to a local end of line convention.

Elkins, et al. Standards Track [Page 6]

RFC 3156 MIME Security with OpenPGP August 2001

(2) Pass both the signed data and its associated content headers
along with the OpenPGP signature to the signature verification
service.

6. Encrypted and Signed Data

Sometimes it is desirable to both digitally sign and then encrypt a
message to be sent. This protocol allows for two methods of
accomplishing this task.

6.1. RFC 1847 Encapsulation

In [2], it is stated that the data is first signed as a
multipart/signature body, and then encrypted to form the final
multipart/encrypted body. This is most useful for standard MIME-
compliant message forwarding.

Example:

Content-Type: multipart/encrypted;
protocol=”application/pgp-encrypted”; boundary=foo

–foo
Content-Type: application/pgp-encrypted

Version: 1

–foo
Content-Type: application/octet-stream

—–BEGIN PGP MESSAGE—–
& Content-Type: multipart/signed; micalg=pgp-md5
& protocol=”application/pgp-signature”; boundary=bar
&
& –bar
& Content-Type: text/plain; charset=us-ascii
&
& This message was first signed, and then encrypted.
&
& –bar
& Content-Type: application/pgp-signature
&
& —–BEGIN PGP MESSAGE—–
& Version: 2.6.2
&
& iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
& jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
& uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn

Elkins, et al. Standards Track [Page 7]

RFC 3156 MIME Security with OpenPGP August 2001

& HOxEa44b+EI=
& =ndaj
& —–END PGP MESSAGE—–
&
& –bar–
—–END PGP MESSAGE—–

–foo–

(The text preceded by ‘&’ indicates that it is really encrypted, but
presented as text for clarity.)

6.2. Combined method

The OpenPGP packet format [1] describes a method for signing and
encrypting data in a single OpenPGP message. This method is allowed
in order to reduce processing overhead and increase compatibility
with non-MIME implementations of OpenPGP. The resulting data is
formatted as a “multipart/encrypted” object as described in Section
4.

Messages which are encrypted and signed in this combined fashion are
REQUIRED to follow the same canonicalization rules as
multipart/signed objects.

It is explicitly allowed for an agent to decrypt a combined message
and rewrite it as a multipart/signed object using the signature data
embedded in the encrypted version.

7. Distribution of OpenPGP public keys

Content-Type: application/pgp-keys
Required parameters: none
Optional parameters: none

A MIME body part of the content type “application/pgp-keys” contains
ASCII-armored transferable Public Key Packets as defined in [1],
section 10.1.

8. Security Considerations

Signatures of a canonical text document as defined in [1] ignore
trailing white space in signed material. Implementations which
choose to use signatures of canonical text documents will not be able
to detect the addition of whitespace in transit.

See [3], [4] for more information on the security considerations
concerning the underlying protocols.

Elkins, et al. Standards Track [Page 8]

RFC 3156 MIME Security with OpenPGP August 2001

9. IANA Considerations

This document defines three media types: “application/pgp-encrypted”,
“application/pgp-signature” and “application/pgp-keys”. The
following sections specify the IANA registrations for these types.

9.1. Registration of the application/pgp-encrypted media type

MIME media type name: application
MIME subtype name: pgp-encrypted
Required parameters: none
Optional parameters: none

Encoding considerations:

Currently this media type always consists of a single 7bit text
string.

Security considerations:

See Section 8 and RFC 2440 Section 13.

Interoperability considerations: none

Published specification:

This document.

Additional information:

Magic number(s): none
File extension(s): none
Macintosh File Type Code(s): none

Person & email address to contact for further information:

Michael Elkins
Email: me@cs.hmc.edu

Intended usage: common

Author/Change controller:

Michael Elkins
Email: me@cs.hmc.edu

Elkins, et al. Standards Track [Page 9]

RFC 3156 MIME Security with OpenPGP August 2001

9.2. Registration of the application/pgp-signature media type

MIME media type name: application
MIME subtype name: pgp-signature
Required parameters: none
Optional parameters: none

Encoding considerations:

The content of this media type always consists of 7bit text.

Security considerations:

See Section 8 and RFC 2440 Section 13.

Interoperability considerations: none

Published specification:

RFC 2440 and this document.

Additional information:

Magic number(s): none
File extension(s): asc, sig
Macintosh File Type Code(s): pgDS

Person & email address to contact for further information:

Michael Elkins
Email: me@cs.hmc.edu

Intended usage: common

Author/Change controller:

Michael Elkins
Email: me@cs.hmc.edu

9.3. Registration of the application/pgp-keys media type

MIME media type name: application
MIME subtype name: pgp-keys
Required parameters: none
Optional parameters: none

Elkins, et al. Standards Track [Page 10]

RFC 3156 MIME Security with OpenPGP August 2001

Encoding considerations:

The content of this media type always consists of 7bit text.

Security considerations:

See Section 8 and RFC 2440 Section 13.

Interoperability considerations: none

Published specification:

RFC 2440 and this document.

Additional information:

Magic number(s): none
File extension(s): asc
Macintosh File Type Code(s): none

Person & email address to contact for further information:

Michael Elkins
Email: me@cs.hmc.edu

Intended usage: common

Author/Change controller:

Michael Elkins
Email: me@cs.hmc.edu

Elkins, et al. Standards Track [Page 11]

RFC 3156 MIME Security with OpenPGP August 2001

10. Notes

“PGP” and “Pretty Good Privacy” are registered trademarks of Network
Associates, Inc.

11. Acknowledgements

This document relies on the work of the IETF’s OpenPGP Working
Group’s definitions of the OpenPGP Message Format. The OpenPGP
message format is currently described in RFC 2440 [1].

Special thanks are due: to Philip Zimmermann for his original and
ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto
for originally proposing the formation of the OpenPGP Working Group;
and to Steve Schoenfeld for helpful feedback during the draft
process. The authors would also like to thank the engineers at
Pretty Good Privacy, Inc (now Network Associates, Inc), including
Colin Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and
Lloyd Chambers, for their technical commentary.

Additional thanks are due to Jeff Schiller and Derek Atkins for their
continuing support of strong cryptography and PGP freeware at MIT; to
Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner
and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; to Bodo
Moeller for proposing the approach followed with respect to trailing
whitespace; to John Gilmore, Hugh Daniel and Fred Ringel (at
Rivertown) and Ian Bell (at Turnpike) for their timely critical
commentary; and to the international members of the IETF’s OpenPGP
mailing list, including William Geiger, Lutz Donnerhacke and Kazu
Yamamoto. The idea to use multipart/mixed with multipart/signed has
been attributed to James Galvin. Finally, our gratitude is due to
the many members of the “Cypherpunks,” “Coderpunks” and “pgp-users”
mailing lists and the many users
of PGP worldwide for helping keep the path to privacy open.

Elkins, et al. Standards Track [Page 12]

RFC 3156 MIME Security with OpenPGP August 2001

12. Addresses of the Authors and OpenPGP Working Group Chair

The OpenPGP working group can be contacted via the current chair:

John W. Noerenberg II
Qualcomm, Inc.
5775 Morehouse Dr.
San Diego, CA 92121 USA

Phone: +1 619 658 3510
EMail: jwn2@qualcomm.com

The principal authors of this document are:

Dave Del Torto
CryptoRights Foundation
80 Alviso Street, Mailstop: CRF
San Francisco, CA 94127 USA

Phone: +1.415.334.5533, vm: #2
EMail: ddt@cryptorights.org, ddt@openpgp.net

Michael Elkins
Network Associates, Inc.
3415 S. Sepulveda Blvd Suite 700
Los Angeles, CA 90034 USA

Phone: +1.310.737.1663
Fax: +1.310.737.1755
Email: me@cs.hmc.edu, Michael_Elkins@NAI.com

Raph Levien
University of California at Berkeley
579 Soda Hall
Berkeley, CA 94720 USA

Phone: +1.510.642.6509
EMail: raph@acm.org

Thomas Roessler
Nordstrasse 99
D-53111 Bonn, Germany

Phone: +49-228-638007
EMail: roessler@does-not-exist.org

Elkins, et al. Standards Track [Page 13]

RFC 3156 MIME Security with OpenPGP August 2001

References

[1] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, “OpenPGP
Message Format”, RFC 2440, November 1998.

[2] Galvin, J., Murphy, G., Crocker, S. and N. Freed, “Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted”,
RFC 1847, October 1995.

[3] Freed, N. and N. Borenstein, “Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types”, RFC 2046, November
1996.

[4] Galvin, J., Murphy, G., Crocker, S. and N. Freed, “MIME Object
Security Services”, RFC 1848, October 1995.

[5] Atkins, D., Stallings, W. and P. Zimmermann, “PGP Message
Exchange Formats”, RFC 1991, August 1996.

[6] Elkins, M., “MIME Security with Pretty Good Privacy (PGP)”, RFC
2015, October 1996.

[7] Freed, N., “Gateways and MIME Security Multiparts”, RFC 2480,
January 1999.

Elkins, et al. Standards Track [Page 14]

RFC 3156 MIME Security with OpenPGP August 2001

Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
“AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Elkins, et al. Standards Track [Page 15] Continue reading “RFC 3156”

RFC 4880

Research, RFC, Technology
Network Working Group                                          J. Callas
Request for Comments: 4880                               PGP Corporation
Obsoletes: 1991, 2440                                     L. Donnerhacke
Category: Standards Track                                       IKS GmbH
                                                               H. Finney
                                                         PGP Corporation
                                                                 D. Shaw
                                                               R. Thayer
                                                           November 2007


                         OpenPGP Message Format

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on the
   OpenPGP format.  It is not a step-by-step cookbook for writing an
   application.  It describes only the format and methods needed to
   read, check, generate, and write conforming packets crossing any
   network.  It does not deal with storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.

   OpenPGP software uses a combination of strong public-key and
   symmetric cryptography to provide security services for electronic
   communications and data storage.  These services include
   confidentiality, key management, authentication, and digital
   signatures.  This document specifies the message formats used in
   OpenPGP.


Callas, et al               Standards Track                     [Page 1]

RFC 4880                 OpenPGP Message Format            November 2007


Table of Contents

   1. Introduction ....................................................5
      1.1. Terms ......................................................5
   2. General functions ...............................................6
      2.1. Confidentiality via Encryption .............................6
      2.2. Authentication via Digital Signature .......................7
      2.3. Compression ................................................7
      2.4. Conversion to Radix-64 .....................................8
      2.5. Signature-Only Applications ................................8
   3. Data Element Formats ............................................8
      3.1. Scalar Numbers .............................................8
      3.2. Multiprecision Integers ....................................9
      3.3. Key IDs ....................................................9
      3.4. Text .......................................................9
      3.5. Time Fields ...............................................10
      3.6. Keyrings ..................................................10
      3.7. String-to-Key (S2K) Specifiers ............................10
           3.7.1. String-to-Key (S2K) Specifier Types ................10
                  3.7.1.1. Simple S2K ................................10
                  3.7.1.2. Salted S2K ................................11
                  3.7.1.3. Iterated and Salted S2K ...................11
           3.7.2. String-to-Key Usage ................................12
                  3.7.2.1. Secret-Key Encryption .....................12
                  3.7.2.2. Symmetric-Key Message Encryption ..........13
   4. Packet Syntax ..................................................13
      4.1. Overview ..................................................13
      4.2. Packet Headers ............................................13
           4.2.1. Old Format Packet Lengths ..........................14
           4.2.2. New Format Packet Lengths ..........................15
                  4.2.2.1. One-Octet Lengths .........................15
                  4.2.2.2. Two-Octet Lengths .........................15
                  4.2.2.3. Five-Octet Lengths ........................15
                  4.2.2.4. Partial Body Lengths ......................16
           4.2.3. Packet Length Examples .............................16
      4.3. Packet Tags ...............................................17
   5. Packet Types ...................................................17
      5.1. Public-Key Encrypted Session Key Packets (Tag 1) ..........17
      5.2. Signature Packet (Tag 2) ..................................19
           5.2.1. Signature Types ....................................19
           5.2.2. Version 3 Signature Packet Format ..................21
           5.2.3. Version 4 Signature Packet Format ..................24
                  5.2.3.1. Signature Subpacket Specification .........25
                  5.2.3.2. Signature Subpacket Types .................27
                  5.2.3.3. Notes on Self-Signatures ..................27
                  5.2.3.4. Signature Creation Time ...................28
                  5.2.3.5. Issuer ....................................28
                  5.2.3.6. Key Expiration Time .......................28



Callas, et al               Standards Track                     [Page 2]

RFC 4880                 OpenPGP Message Format            November 2007


                  5.2.3.7. Preferred Symmetric Algorithms ............28
                  5.2.3.8. Preferred Hash Algorithms .................29
                  5.2.3.9. Preferred Compression Algorithms ..........29
                  5.2.3.10. Signature Expiration Time ................29
                  5.2.3.11. Exportable Certification .................29
                  5.2.3.12. Revocable ................................30
                  5.2.3.13. Trust Signature ..........................30
                  5.2.3.14. Regular Expression .......................31
                  5.2.3.15. Revocation Key ...........................31
                  5.2.3.16. Notation Data ............................31
                  5.2.3.17. Key Server Preferences ...................32
                  5.2.3.18. Preferred Key Server .....................33
                  5.2.3.19. Primary User ID ..........................33
                  5.2.3.20. Policy URI ...............................33
                  5.2.3.21. Key Flags ................................33
                  5.2.3.22. Signer's User ID .........................34
                  5.2.3.23. Reason for Revocation ....................35
                  5.2.3.24. Features .................................36
                  5.2.3.25. Signature Target .........................36
                  5.2.3.26. Embedded Signature .......................37
           5.2.4. Computing Signatures ...............................37
                  5.2.4.1. Subpacket Hints ...........................38
      5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) .......38
      5.4. One-Pass Signature Packets (Tag 4) ........................39
      5.5. Key Material Packet .......................................40
           5.5.1. Key Packet Variants ................................40
                  5.5.1.1. Public-Key Packet (Tag 6) .................40
                  5.5.1.2. Public-Subkey Packet (Tag 14) .............40
                  5.5.1.3. Secret-Key Packet (Tag 5) .................41
                  5.5.1.4. Secret-Subkey Packet (Tag 7) ..............41
           5.5.2. Public-Key Packet Formats ..........................41
           5.5.3. Secret-Key Packet Formats ..........................43
      5.6. Compressed Data Packet (Tag 8) ............................45
      5.7. Symmetrically Encrypted Data Packet (Tag 9) ...............45
      5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) ..........46
      5.9. Literal Data Packet (Tag 11) ..............................46
      5.10. Trust Packet (Tag 12) ....................................47
      5.11. User ID Packet (Tag 13) ..................................48
      5.12. User Attribute Packet (Tag 17) ...........................48
           5.12.1. The Image Attribute Subpacket .....................48
      5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) ..49
      5.14. Modification Detection Code Packet (Tag 19) ..............52
   6. Radix-64 Conversions ...........................................53
      6.1. An Implementation of the CRC-24 in "C" ....................54
      6.2. Forming ASCII Armor .......................................54
      6.3. Encoding Binary in Radix-64 ...............................57
      6.4. Decoding Radix-64 .........................................58
      6.5. Examples of Radix-64 ......................................59



Callas, et al               Standards Track                     [Page 3]

RFC 4880                 OpenPGP Message Format            November 2007


      6.6. Example of an ASCII Armored Message .......................59
   7. Cleartext Signature Framework ..................................59
      7.1. Dash-Escaped Text .........................................60
   8. Regular Expressions ............................................61
   9. Constants ......................................................61
      9.1. Public-Key Algorithms .....................................62
      9.2. Symmetric-Key Algorithms ..................................62
      9.3. Compression Algorithms ....................................63
      9.4. Hash Algorithms ...........................................63
   10. IANA Considerations ...........................................63
      10.1. New String-to-Key Specifier Types ........................64
      10.2. New Packets ..............................................64
           10.2.1. User Attribute Types ..............................64
                  10.2.1.1. Image Format Subpacket Types .............64
           10.2.2. New Signature Subpackets ..........................64
                  10.2.2.1. Signature Notation Data Subpackets .......65
                  10.2.2.2. Key Server Preference Extensions .........65
                  10.2.2.3. Key Flags Extensions .....................65
                  10.2.2.4. Reason For Revocation Extensions .........65
                  10.2.2.5. Implementation Features ..................66
           10.2.3. New Packet Versions ...............................66
      10.3. New Algorithms ...........................................66
           10.3.1. Public-Key Algorithms .............................66
           10.3.2. Symmetric-Key Algorithms ..........................67
           10.3.3. Hash Algorithms ...................................67
           10.3.4. Compression Algorithms ............................67
   11. Packet Composition ............................................67
      11.1. Transferable Public Keys .................................67
      11.2. Transferable Secret Keys .................................69
      11.3. OpenPGP Messages .........................................69
      11.4. Detached Signatures ......................................70
   12. Enhanced Key Formats ..........................................70
      12.1. Key Structures ...........................................70
      12.2. Key IDs and Fingerprints .................................71
   13. Notes on Algorithms ...........................................72
      13.1. PKCS#1 Encoding in OpenPGP ...............................72
           13.1.1. EME-PKCS1-v1_5-ENCODE .............................73
           13.1.2. EME-PKCS1-v1_5-DECODE .............................73
           13.1.3. EMSA-PKCS1-v1_5 ...................................74
      13.2. Symmetric Algorithm Preferences ..........................75
      13.3. Other Algorithm Preferences ..............................76
           13.3.1. Compression Preferences ...........................76
           13.3.2. Hash Algorithm Preferences ........................76
      13.4. Plaintext ................................................77
      13.5. RSA ......................................................77
      13.6. DSA ......................................................77
      13.7. Elgamal ..................................................78
      13.8. Reserved Algorithm Numbers ...............................78



Callas, et al               Standards Track                     [Page 4]

RFC 4880                 OpenPGP Message Format            November 2007


      13.9. OpenPGP CFB Mode .........................................78
      13.10. Private or Experimental Parameters ......................79
      13.11. Extension of the MDC System .............................80
      13.12. Meta-Considerations for Expansion .......................80
   14. Security Considerations .......................................81
   15. Implementation Nits ...........................................84
   16. References ....................................................86
      16.1. Normative References .....................................86
      16.2. Informative References ...................................88

1.  Introduction

   This document provides information on the message-exchange packet
   formats used by OpenPGP to provide encryption, decryption, signing,
   and key management functions.  It is a revision of RFC 2440, "OpenPGP
   Message Format", which itself replaces RFC 1991, "PGP Message
   Exchange Formats" [RFC1991] [RFC2440].

1.1.  Terms

     * OpenPGP - This is a term for security software that uses PGP 5.x
       as a basis, formalized in RFC 2440 and this document.

     * PGP - Pretty Good Privacy.  PGP is a family of software systems
       developed by Philip R. Zimmermann from which OpenPGP is based.

     * PGP 2.6.x - This version of PGP has many variants, hence the term
       PGP 2.6.x.  It used only RSA, MD5, and IDEA for its cryptographic
       transforms.  An informational RFC, RFC 1991, was written
       describing this version of PGP.

     * PGP 5.x - This version of PGP is formerly known as "PGP 3" in the
       community and also in the predecessor of this document, RFC 1991.
       It has new formats and corrects a number of problems in the PGP
       2.6.x design.  It is referred to here as PGP 5.x because that
       software was the first release of the "PGP 3" code base.

     * GnuPG - GNU Privacy Guard, also called GPG.  GnuPG is an OpenPGP
       implementation that avoids all encumbered algorithms.
       Consequently, early versions of GnuPG did not include RSA public
       keys.  GnuPG may or may not have (depending on version) support
       for IDEA or other encumbered algorithms.

   "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP
   Corporation and are used with permission.  The term "OpenPGP" refers
   to the protocol described in this and related documents.





Callas, et al               Standards Track                     [Page 5]

RFC 4880                 OpenPGP Message Format            November 2007


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
   FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
   APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
   this document when used to describe namespace allocation are to be
   interpreted as described in [RFC2434].

2.  General functions

   OpenPGP provides data integrity services for messages and data files
   by using these core technologies:

     - digital signatures

     - encryption

     - compression

     - Radix-64 conversion

   In addition, OpenPGP provides key management and certificate
   services, but many of these are beyond the scope of this document.

2.1.  Confidentiality via Encryption

   OpenPGP combines symmetric-key encryption and public-key encryption
   to provide confidentiality.  When made confidential, first the object
   is encrypted using a symmetric encryption algorithm.  Each symmetric
   key is used only once, for a single object.  A new "session key" is
   generated as a random number for each object (sometimes referred to
   as a session).  Since it is used only once, the session key is bound
   to the message and transmitted with it.  To protect the key, it is
   encrypted with the receiver's public key.  The sequence is as
   follows:

   1.  The sender creates a message.

   2.  The sending OpenPGP generates a random number to be used as a
       session key for this message only.

   3.  The session key is encrypted using each recipient's public key.
       These "encrypted session keys" start the message.


Callas, et al               Standards Track                     [Page 6]

RFC 4880                 OpenPGP Message Format            November 2007


   4.  The sending OpenPGP encrypts the message using the session key,
       which forms the remainder of the message.  Note that the message
       is also usually compressed.

   5.  The receiving OpenPGP decrypts the session key using the
       recipient's private key.

   6.  The receiving OpenPGP decrypts the message using the session key.
       If the message was compressed, it will be decompressed.

   With symmetric-key encryption, an object may be encrypted with a
   symmetric key derived from a passphrase (or other shared secret), or
   a two-stage mechanism similar to the public-key method described
   above in which a session key is itself encrypted with a symmetric
   algorithm keyed from a shared secret.

   Both digital signature and confidentiality services may be applied to
   the same message.  First, a signature is generated for the message
   and attached to the message.  Then the message plus signature is
   encrypted using a symmetric session key.  Finally, the session key is
   encrypted using public-key encryption and prefixed to the encrypted
   block.

2.2.  Authentication via Digital Signature

   The digital signature uses a hash code or message digest algorithm,
   and a public-key signature algorithm.  The sequence is as follows:

   1.  The sender creates a message.

   2.  The sending software generates a hash code of the message.

   3.  The sending software generates a signature from the hash code
       using the sender's private key.

   4.  The binary signature is attached to the message.

   5.  The receiving software keeps a copy of the message signature.

   6.  The receiving software generates a new hash code for the received
       message and verifies it using the message's signature.  If the
       verification is successful, the message is accepted as authentic.

2.3.  Compression

   OpenPGP implementations SHOULD compress the message after applying
   the signature but before encryption.


Callas, et al               Standards Track                     [Page 7]

RFC 4880                 OpenPGP Message Format            November 2007


   If an implementation does not implement compression, its authors
   should be aware that most OpenPGP messages in the world are
   compressed.  Thus, it may even be wise for a space-constrained
   implementation to implement decompression, but not compression.

   Furthermore, compression has the added side effect that some types of
   attacks can be thwarted by the fact that slightly altered, compressed
   data rarely uncompresses without severe errors.  This is hardly
   rigorous, but it is operationally useful.  These attacks can be
   rigorously prevented by implementing and using Modification Detection
   Codes as described in sections following.

2.4.  Conversion to Radix-64

   OpenPGP's underlying native representation for encrypted messages,
   signature certificates, and keys is a stream of arbitrary octets.
   Some systems only permit the use of blocks consisting of seven-bit,
   printable text.  For transporting OpenPGP's native raw binary octets
   through channels that are not safe to raw binary data, a printable
   encoding of these binary octets is needed.  OpenPGP provides the
   service of converting the raw 8-bit binary octet stream to a stream
   of printable ASCII characters, called Radix-64 encoding or ASCII
   Armor.

   Implementations SHOULD provide Radix-64 conversions.

2.5.  Signature-Only Applications

   OpenPGP is designed for applications that use both encryption and
   signatures, but there are a number of problems that are solved by a
   signature-only implementation.  Although this specification requires
   both encryption and signatures, it is reasonable for there to be
   subset implementations that are non-conformant only in that they omit
   encryption.

3.  Data Element Formats

   This section describes the data elements used by OpenPGP.

3.1.  Scalar Numbers

   Scalar numbers are unsigned and are always stored in big-endian
   format.  Using n[k] to refer to the kth octet being interpreted, the
   value of a two-octet scalar is ((n[0] << 8) + n[1]).  The value of a
   four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
   n[3]).



Callas, et al               Standards Track                     [Page 8]

RFC 4880                 OpenPGP Message Format            November 2007


3.2.  Multiprecision Integers

   Multiprecision integers (also called MPIs) are unsigned integers used
   to hold large integers such as the ones used in cryptographic
   calculations.

   An MPI consists of two pieces: a two-octet scalar that is the length
   of the MPI in bits followed by a string of octets that contain the
   actual integer.

   These octets form a big-endian number; a big-endian number can be
   made into an MPI by prefixing it with the appropriate length.

   Examples:

   (all numbers are in hexadecimal)

   The string of octets [00 01 01] forms an MPI with the value 1.  The
   string [00 09 01 FF] forms an MPI with the value of 511.

   Additional rules:

   The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.

   The length field of an MPI describes the length starting from its
   most significant non-zero bit.  Thus, the MPI [00 02 01] is not
   formed correctly.  It should be [00 01 01].

   Unused bits of an MPI MUST be zero.

   Also note that when an MPI is encrypted, the length refers to the
   plaintext MPI.  It may be ill-formed in its ciphertext.

3.3.  Key IDs

   A Key ID is an eight-octet scalar that identifies a key.
   Implementations SHOULD NOT assume that Key IDs are unique.  The
   section "Enhanced Key Formats" below describes how Key IDs are
   formed.

3.4.  Text

   Unless otherwise specified, the character set for text is the UTF-8
   [RFC3629] encoding of Unicode [ISO10646].


Callas, et al               Standards Track                     [Page 9]

RFC 4880                 OpenPGP Message Format            November 2007


3.5.  Time Fields

   A time field is an unsigned four-octet number containing the number
   of seconds elapsed since midnight, 1 January 1970 UTC.

3.6.  Keyrings

   A keyring is a collection of one or more keys in a file or database.
   Traditionally, a keyring is simply a sequential list of keys, but may
   be any suitable database.  It is beyond the scope of this standard to
   discuss the details of keyrings or other databases.

3.7.  String-to-Key (S2K) Specifiers

   String-to-key (S2K) specifiers are used to convert passphrase strings
   into symmetric-key encryption/decryption keys.  They are used in two
   places, currently: to encrypt the secret part of private keys in the
   private keyring, and to convert passphrases to encryption keys for
   symmetrically encrypted messages.

3.7.1.  String-to-Key (S2K) Specifier Types

   There are three types of S2K specifiers currently supported, and
   some reserved values:

       ID          S2K Type
       --          --------
       0           Simple S2K
       1           Salted S2K
       2           Reserved value
       3           Iterated and Salted S2K
       100 to 110  Private/Experimental S2K

   These are described in Sections 3.7.1.1 - 3.7.1.3.

3.7.1.1.  Simple S2K

   This directly hashes the string to produce the key data.  See below
   for how this hashing is done.

       Octet 0:        0x00
       Octet 1:        hash algorithm

   Simple S2K hashes the passphrase to produce the session key.  The
   manner in which this is done depends on the size of the session key
   (which will depend on the cipher used) and the size of the hash



Callas, et al               Standards Track                    [Page 10]

RFC 4880                 OpenPGP Message Format            November 2007


   algorithm's output.  If the hash size is greater than the session key
   size, the high-order (leftmost) octets of the hash are used as the
   key.

   If the hash size is less than the key size, multiple instances of the
   hash context are created -- enough to produce the required key data.
   These instances are preloaded with 0, 1, 2, ... octets of zeros (that
   is to say, the first instance has no preloading, the second gets
   preloaded with 1 octet of zero, the third is preloaded with two
   octets of zeros, and so forth).

   As the data is hashed, it is given independently to each hash
   context.  Since the contexts have been initialized differently, they
   will each produce different hash output.  Once the passphrase is
   hashed, the output data from the multiple hashes is concatenated,
   first hash leftmost, to produce the key data, with any excess octets
   on the right discarded.

3.7.1.2.  Salted S2K

   This includes a "salt" value in the S2K specifier -- some arbitrary
   data -- that gets hashed along with the passphrase string, to help
   prevent dictionary attacks.

       Octet 0:        0x01
       Octet 1:        hash algorithm
       Octets 2-9:     8-octet salt value

   Salted S2K is exactly like Simple S2K, except that the input to the
   hash function(s) consists of the 8 octets of salt from the S2K
   specifier, followed by the passphrase.

3.7.1.3.  Iterated and Salted S2K

   This includes both a salt and an octet count.  The salt is combined
   with the passphrase and the resulting value is hashed repeatedly.
   This further increases the amount of work an attacker must do to try
   dictionary attacks.

       Octet  0:        0x03
       Octet  1:        hash algorithm
       Octets 2-9:      8-octet salt value
       Octet  10:       count, a one-octet, coded value



Callas, et al               Standards Track                    [Page 11]

RFC 4880                 OpenPGP Message Format            November 2007


   The count is coded into a one-octet number using the following
   formula:

       #define EXPBIAS 6
           count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

   The above formula is in C, where "Int32" is a type for a 32-bit
   integer, and the variable "c" is the coded count, Octet 10.

   Iterated-Salted S2K hashes the passphrase and salt data multiple
   times.  The total number of octets to be hashed is specified in the
   encoded count in the S2K specifier.  Note that the resulting count
   value is an octet count of how many octets will be hashed, not an
   iteration count.

   Initially, one or more hash contexts are set up as with the other S2K
   algorithms, depending on how many octets of key data are needed.
   Then the salt, followed by the passphrase data, is repeatedly hashed
   until the number of octets specified by the octet count has been
   hashed.  The one exception is that if the octet count is less than
   the size of the salt plus passphrase, the full salt plus passphrase
   will be hashed even though that is greater than the octet count.
   After the hashing is done, the data is unloaded from the hash
   context(s) as with the other S2K algorithms.

3.7.2.  String-to-Key Usage

   Implementations SHOULD use salted or iterated-and-salted S2K
   specifiers, as simple S2K specifiers are more vulnerable to
   dictionary attacks.

3.7.2.1.  Secret-Key Encryption

   An S2K specifier can be stored in the secret keyring to specify how
   to convert the passphrase to a key that unlocks the secret data.
   Older versions of PGP just stored a cipher algorithm octet preceding
   the secret data or a zero to indicate that the secret data was
   unencrypted.  The MD5 hash function was always used to convert the
   passphrase to a key for the specified cipher algorithm.

   For compatibility, when an S2K specifier is used, the special value
   254 or 255 is stored in the position where the hash algorithm octet
   would have been in the old data structure.  This is then followed
   immediately by a one-octet algorithm identifier, and then by the S2K
   specifier as encoded above.



Callas, et al               Standards Track                    [Page 12]

RFC 4880                 OpenPGP Message Format            November 2007


   Therefore, preceding the secret data there will be one of these
   possibilities:

       0:           secret data is unencrypted (no passphrase)
       255 or 254:  followed by algorithm octet and S2K specifier
       Cipher alg:  use Simple S2K algorithm using MD5 hash

   This last possibility, the cipher algorithm number with an implicit
   use of MD5 and IDEA, is provided for backward compatibility; it MAY
   be understood, but SHOULD NOT be generated, and is deprecated.

   These are followed by an Initial Vector of the same length as the
   block size of the cipher for the decryption of the secret values, if
   they are encrypted, and then the secret-key values themselves.

3.7.2.2.  Symmetric-Key Message Encryption

   OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet
   at the front of a message.  This is used to allow S2K specifiers to
   be used for the passphrase conversion or to create messages with a
   mix of symmetric-key ESKs and public-key ESKs.  This allows a message
   to be decrypted either with a passphrase or a public-key pair.

   PGP 2.X always used IDEA with Simple string-to-key conversion when
   encrypting a message with a symmetric algorithm.  This is deprecated,
   but MAY be used for backward-compatibility.

4.  Packet Syntax

   This section describes the packets used by OpenPGP.

4.1.  Overview

   An OpenPGP message is constructed from a number of records that are
   traditionally called packets.  A packet is a chunk of data that has a
   tag specifying its meaning.  An OpenPGP message, keyring,
   certificate, and so forth consists of a number of packets.  Some of
   those packets may contain other OpenPGP packets (for example, a
   compressed data packet, when uncompressed, contains OpenPGP packets).

   Each packet consists of a packet header, followed by the packet body.
   The packet header is of variable length.

4.2.  Packet Headers

   The first octet of the packet header is called the "Packet Tag".  It
   determines the format of the header and denotes the packet contents.
   The remainder of the packet header is the length of the packet.



Callas, et al               Standards Track                    [Page 13]

RFC 4880                 OpenPGP Message Format            November 2007


   Note that the most significant bit is the leftmost bit, called bit 7.
   A mask for this bit is 0x80 in hexadecimal.

              +---------------+
         PTag |7 6 5 4 3 2 1 0|
              +---------------+
         Bit 7 -- Always one
         Bit 6 -- New packet format if set

   PGP 2.6.x only uses old format packets.  Thus, software that
   interoperates with those versions of PGP must only use old format
   packets.  If interoperability is not an issue, the new packet format
   is RECOMMENDED.  Note that old format packets have four bits of
   packet tags, and new format packets have six; some features cannot be
   used and still be backward-compatible.

   Also note that packets with a tag greater than or equal to 16 MUST
   use new format packets.  The old format packets can only express tags
   less than or equal to 15.

   Old format packets contain:

         Bits 5-2 -- packet tag
         Bits 1-0 -- length-type

   New format packets contain:

         Bits 5-0 -- packet tag

4.2.1.  Old Format Packet Lengths

   The meaning of the length-type in old format packets is:

   0 - The packet has a one-octet length.  The header is 2 octets long.

   1 - The packet has a two-octet length.  The header is 3 octets long.

   2 - The packet has a four-octet length.  The header is 5 octets long.

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
       is.  If the packet is in a file, this means that the packet
       extends until the end of the file.  In general, an implementation
       SHOULD NOT use indeterminate-length packets except where the end
       of the data will be clear from the context, and even then it is
       better to use a definite length, or a new format header.  The new
       format headers described below have a mechanism for precisely
       encoding data of indeterminate length.



Callas, et al               Standards Track                    [Page 14]

RFC 4880                 OpenPGP Message Format            November 2007


4.2.2.  New Format Packet Lengths

   New format packets have four possible ways of encoding length:

   1. A one-octet Body Length header encodes packet lengths of up to 191
      octets.

   2. A two-octet Body Length header encodes packet lengths of 192 to
      8383 octets.

   3. A five-octet Body Length header encodes packet lengths of up to
      4,294,967,295 (0xFFFFFFFF) octets in length.  (This actually
      encodes a four-octet scalar number.)

   4. When the length of the packet body is not known in advance by the
      issuer, Partial Body Length headers encode a packet of
      indeterminate length, effectively making it a stream.

4.2.2.1.  One-Octet Lengths

   A one-octet Body Length header encodes a length of 0 to 191 octets.
   This type of length header is recognized because the one octet value
   is less than 192.  The body length is equal to:

       bodyLen = 1st_octet;

4.2.2.2.  Two-Octet Lengths

   A two-octet Body Length header encodes a length of 192 to 8383
   octets.  It is recognized because its first octet is in the range 192
   to 223.  The body length is equal to:

       bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

4.2.2.3.  Five-Octet Lengths

   A five-octet Body Length header consists of a single octet holding
   the value 255, followed by a four-octet scalar.  The body length is
   equal to:

       bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
                 (4th_octet << 8)  | 5th_octet

   This basic set of one, two, and five-octet lengths is also used
   internally to some packets.


Callas, et al               Standards Track                    [Page 15]

RFC 4880                 OpenPGP Message Format            November 2007


4.2.2.4.  Partial Body Lengths

   A Partial Body Length header is one octet long and encodes the length
   of only part of the data packet.  This length is a power of 2, from 1
   to 1,073,741,824 (2 to the 30th power).  It is recognized by its one
   octet value that is greater than or equal to 224, and less than 255.
   The Partial Body Length is equal to:

       partialBodyLen = 1 << (1st_octet & 0x1F);

   Each Partial Body Length header is followed by a portion of the
   packet body data.  The Partial Body Length header specifies this
   portion's length.  Another length header (one octet, two-octet,
   five-octet, or partial) follows that portion.  The last length header
   in the packet MUST NOT be a Partial Body Length header.  Partial Body
   Length headers may only be used for the non-final parts of the
   packet.

   Note also that the last Body Length header can be a zero-length
   header.

   An implementation MAY use Partial Body Lengths for data packets, be
   they literal, compressed, or encrypted.  The first partial length
   MUST be at least 512 octets long.  Partial Body Lengths MUST NOT be
   used for any other packet types.

4.2.3.  Packet Length Examples

   These examples show ways that new format packets might encode the
   packet lengths.

   A packet with length 100 may have its length encoded in one octet:
   0x64.  This is followed by 100 octets of data.

   A packet with length 1723 may have its length encoded in two octets:
   0xC5, 0xFB.  This header is followed by the 1723 octets of data.

   A packet with length 100000 may have its length encoded in five
   octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.

   It might also be encoded in the following octet stream: 0xEF, first
   32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
   octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693
   octets of data.  This is just one possible encoding, and many
   variations are possible on the size of the Partial Body Length
   headers, as long as a regular Body Length header encodes the last
   portion of the data.




Callas, et al               Standards Track                    [Page 16]

RFC 4880                 OpenPGP Message Format            November 2007


   Please note that in all of these explanations, the total length of
   the packet is the length of the header(s) plus the length of the
   body.

4.3.  Packet Tags

   The packet tag denotes what type of packet the body holds.  Note that
   old format headers can only have tags less than 16, whereas new
   format headers can have tags as great as 63.  The defined tags (in
   decimal) are as follows:

       0        -- Reserved - a packet tag MUST NOT have this value
       1        -- Public-Key Encrypted Session Key Packet
       2        -- Signature Packet
       3        -- Symmetric-Key Encrypted Session Key Packet
       4        -- One-Pass Signature Packet
       5        -- Secret-Key Packet
       6        -- Public-Key Packet
       7        -- Secret-Subkey Packet
       8        -- Compressed Data Packet
       9        -- Symmetrically Encrypted Data Packet
       10       -- Marker Packet
       11       -- Literal Data Packet
       12       -- Trust Packet
       13       -- User ID Packet
       14       -- Public-Subkey Packet
       17       -- User Attribute Packet
       18       -- Sym. Encrypted and Integrity Protected Data Packet
       19       -- Modification Detection Code Packet
       60 to 63 -- Private or Experimental Values

5.  Packet Types

5.1.  Public-Key Encrypted Session Key Packets (Tag 1)

   A Public-Key Encrypted Session Key packet holds the session key used
   to encrypt a message.  Zero or more Public-Key Encrypted Session Key
   packets and/or Symmetric-Key Encrypted Session Key packets may
   precede a Symmetrically Encrypted Data Packet, which holds an
   encrypted message.  The message is encrypted with the session key,
   and the session key is itself encrypted and stored in the Encrypted
   Session Key packet(s).  The Symmetrically Encrypted Data Packet is
   preceded by one Public-Key Encrypted Session Key packet for each
   OpenPGP key to which the message is encrypted.  The recipient of the
   message finds a session key that is encrypted to their public key,
   decrypts the session key, and then uses the session key to decrypt
   the message.


Callas, et al               Standards Track                    [Page 17]

RFC 4880                 OpenPGP Message Format            November 2007


   The body of this packet consists of:

     - A one-octet number giving the version number of the packet type.
       The currently defined value for packet version is 3.

     - An eight-octet number that gives the Key ID of the public key to
       which the session key is encrypted.  If the session key is
       encrypted to a subkey, then the Key ID of this subkey is used
       here instead of the Key ID of the primary key.

     - A one-octet number giving the public-key algorithm used.

     - A string of octets that is the encrypted session key.  This
       string takes up the remainder of the packet, and its contents are
       dependent on the public-key algorithm used.

   Algorithm Specific Fields for RSA encryption

     - multiprecision integer (MPI) of RSA encrypted value m**e mod n.

   Algorithm Specific Fields for Elgamal encryption:

     - MPI of Elgamal (Diffie-Hellman) value g**k mod p.

     - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.

   The value "m" in the above formulas is derived from the session key
   as follows.  First, the session key is prefixed with a one-octet
   algorithm identifier that specifies the symmetric encryption
   algorithm used to encrypt the following Symmetrically Encrypted Data
   Packet.  Then a two-octet checksum is appended, which is equal to the
   sum of the preceding session key octets, not including the algorithm
   identifier, modulo 65536.  This value is then encoded as described in
   PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to
   form the "m" value used in the formulas above.  See Section 13.1 of
   this document for notes on OpenPGP's use of PKCS#1.

   Note that when an implementation forms several PKESKs with one
   session key, forming a message that can be decrypted by several keys,
   the implementation MUST make a new PKCS#1 encoding for each key.

   An implementation MAY accept or use a Key ID of zero as a "wild card"
   or "speculative" Key ID.  In this case, the receiving implementation
   would try all available private keys, checking for a valid decrypted
   session key.  This format helps reduce traffic analysis of messages.


Callas, et al               Standards Track                    [Page 18]

RFC 4880                 OpenPGP Message Format            November 2007


5.2.  Signature Packet (Tag 2)

   A Signature packet describes a binding between some public key and
   some data.  The most common signatures are a signature of a file or a
   block of text, and a signature that is a certification of a User ID.

   Two versions of Signature packets are defined.  Version 3 provides
   basic signature information, while version 4 provides an expandable
   format with subpackets that can specify more information about the
   signature.  PGP 2.6.x only accepts version 3 signatures.

   Implementations SHOULD accept V3 signatures.  Implementations SHOULD
   generate V4 signatures.

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted to a V3 key, it is reasonable to create a
   V3 signature.

5.2.1.  Signature Types

   There are a number of possible meanings for a signature, which are
   indicated in a signature type octet in any given signature.  Please
   note that the vagueness of these meanings is not a flaw, but a
   feature of the system.  Because OpenPGP places final authority for
   validity upon the receiver of a signature, it may be that one
   signer's casual act might be more rigorous than some other
   authority's positive act.  See Section 5.2.4, "Computing Signatures",
   for detailed information on how to compute and verify signatures of
   each type.

   These meanings are as follows:

   0x00: Signature of a binary document.
       This means the signer owns it, created it, or certifies that it
       has not been modified.

   0x01: Signature of a canonical text document.
       This means the signer owns it, created it, or certifies that it
       has not been modified.  The signature is calculated over the text
       data with its line endings converted to <CR><LF>.

   0x02: Standalone signature.
       This signature is a signature of only its own subpacket contents.
       It is calculated identically to a signature over a zero-length
       binary document.  Note that it doesn't make sense to have a V3
       standalone signature.





Callas, et al               Standards Track                    [Page 19]

RFC 4880                 OpenPGP Message Format            November 2007


   0x10: Generic certification of a User ID and Public-Key packet.
       The issuer of this certification does not make any particular
       assertion as to how well the certifier has checked that the owner
       of the key is in fact the person described by the User ID.

   0x11: Persona certification of a User ID and Public-Key packet.
       The issuer of this certification has not done any verification of
       the claim that the owner of this key is the User ID specified.

   0x12: Casual certification of a User ID and Public-Key packet.
       The issuer of this certification has done some casual
       verification of the claim of identity.

   0x13: Positive certification of a User ID and Public-Key packet.
       The issuer of this certification has done substantial
       verification of the claim of identity.

       Most OpenPGP implementations make their "key signatures" as 0x10
       certifications.  Some implementations can issue 0x11-0x13
       certifications, but few differentiate between the types.

   0x18: Subkey Binding Signature
       This signature is a statement by the top-level signing key that
       indicates that it owns the subkey.  This signature is calculated
       directly on the primary key and subkey, and not on any User ID or
       other packets.  A signature that binds a signing subkey MUST have
       an Embedded Signature subpacket in this binding signature that
       contains a 0x19 signature made by the signing subkey on the
       primary key and subkey.

   0x19: Primary Key Binding Signature
       This signature is a statement by a signing subkey, indicating
       that it is owned by the primary key and subkey.  This signature
       is calculated the same way as a 0x18 signature: directly on the
       primary key and subkey, and not on any User ID or other packets.

   0x1F: Signature directly on a key
       This signature is calculated directly on a key.  It binds the
       information in the Signature subpackets to the key, and is
       appropriate to be used for subpackets that provide information
       about the key, such as the Revocation Key subpacket.  It is also
       appropriate for statements that non-self certifiers want to make
       about the key itself, rather than the binding between a key and a
       name.


Callas, et al               Standards Track                    [Page 20]

RFC 4880                 OpenPGP Message Format            November 2007


   0x20: Key revocation signature
       The signature is calculated directly on the key being revoked.  A
       revoked key is not to be used.  Only revocation signatures by the
       key being revoked, or by an authorized revocation key, should be
       considered valid revocation signatures.

   0x28: Subkey revocation signature
       The signature is calculated directly on the subkey being revoked.
       A revoked subkey is not to be used.  Only revocation signatures
       by the top-level signature key that is bound to this subkey, or
       by an authorized revocation key, should be considered valid
       revocation signatures.

   0x30: Certification revocation signature
       This signature revokes an earlier User ID certification signature
       (signature class 0x10 through 0x13) or direct-key signature
       (0x1F).  It should be issued by the same key that issued the
       revoked signature or an authorized revocation key.  The signature
       is computed over the same data as the certificate that it
       revokes, and should have a later creation date than that
       certificate.

   0x40: Timestamp signature.
       This signature is only meaningful for the timestamp contained in
       it.

   0x50: Third-Party Confirmation signature.
       This signature is a signature over some other OpenPGP Signature
       packet(s).  It is analogous to a notary seal on the signed data.
       A third-party signature SHOULD include Signature Target
       subpacket(s) to give easy identification.  Note that we really do
       mean SHOULD.  There are plausible uses for this (such as a blind
       party that only sees the signature, not the key or source
       document) that cannot include a target subpacket.

5.2.2.  Version 3 Signature Packet Format

   The body of a version 3 Signature Packet contains:

     - One-octet version number (3).

     - One-octet length of following hashed material.  MUST be 5.

         - One-octet signature type.

         - Four-octet creation time.

     - Eight-octet Key ID of signer.



Callas, et al               Standards Track                    [Page 21]

RFC 4880                 OpenPGP Message Format            November 2007


     - One-octet public-key algorithm.

     - One-octet hash algorithm.

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multiprecision integers comprising the signature.
       This portion is algorithm specific, as described below.

   The concatenation of the data to be signed, the signature type, and
   creation time from the Signature packet (5 additional octets) is
   hashed.  The resulting hash value is used in the signature algorithm.
   The high 16 bits (first two octets) of the hash are included in the
   Signature packet to provide a quick test to reject some invalid
   signatures.

   Algorithm-Specific Fields for RSA signatures:

     - multiprecision integer (MPI) of RSA signature value m**d mod n.

   Algorithm-Specific Fields for DSA signatures:

     - MPI of DSA value r.

     - MPI of DSA value s.

   The signature calculation is based on a hash of the signed data, as
   described above.  The details of the calculation are different for
   DSA signatures than for RSA signatures.

   With RSA signatures, the hash value is encoded using PKCS#1 encoding
   type EMSA-PKCS1-v1_5 as described in Section 9.2 of RFC 3447.  This
   requires inserting the hash value as an octet string into an ASN.1
   structure.  The object identifier for the type of hash being used is
   included in the structure.  The hexadecimal representations for the
   currently defined hash algorithms are as follows:

     - MD5:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05

     - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01

     - SHA-1:      0x2B, 0x0E, 0x03, 0x02, 0x1A

     - SHA224:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04

     - SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01

     - SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02



Callas, et al               Standards Track                    [Page 22]

RFC 4880                 OpenPGP Message Format            November 2007


     - SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03

   The ASN.1 Object Identifiers (OIDs) are as follows:

     - MD5:        1.2.840.113549.2.5

     - RIPEMD-160: 1.3.36.3.2.1

     - SHA-1:      1.3.14.3.2.26

     - SHA224:     2.16.840.1.101.3.4.2.4

     - SHA256:     2.16.840.1.101.3.4.2.1

     - SHA384:     2.16.840.1.101.3.4.2.2

     - SHA512:     2.16.840.1.101.3.4.2.3

   The full hash prefixes for these are as follows:

       MD5:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
                   0x04, 0x10

       RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
                   0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14

       SHA-1:      0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
                   0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14

       SHA224:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
                   0x00, 0x04, 0x1C

       SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
                   0x00, 0x04, 0x20

       SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
                   0x00, 0x04, 0x30

       SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
                   0x00, 0x04, 0x40

   DSA signatures MUST use hashes that are equal in size to the number
   of bits of q, the group generated by the DSA key's generator value.



Callas, et al               Standards Track                    [Page 23]

RFC 4880                 OpenPGP Message Format            November 2007


   If the output size of the chosen hash is larger than the number of
   bits of q, the hash result is truncated to fit by taking the number
   of leftmost bits equal to the number of bits of q.  This (possibly
   truncated) hash function result is treated as a number and used
   directly in the DSA signature algorithm.

5.2.3.  Version 4 Signature Packet Format

   The body of a version 4 Signature packet contains:

     - One-octet version number (4).

     - One-octet signature type.

     - One-octet public-key algorithm.

     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket data.
       Note that this is the length in octets of all of the hashed
       subpackets; a pointer incremented by this number will skip over
       the hashed subpackets.

     - Hashed subpacket data set (zero or more subpackets).

     - Two-octet scalar octet count for the following unhashed subpacket
       data.  Note that this is the length in octets of all of the
       unhashed subpackets; a pointer incremented by this number will
       skip over the unhashed subpackets.

     - Unhashed subpacket data set (zero or more subpackets).

     - Two-octet field holding the left 16 bits of the signed hash
       value.

     - One or more multiprecision integers comprising the signature.
       This portion is algorithm specific, as described above.

   The concatenation of the data being signed and the signature data
   from the version number through the hashed subpacket data (inclusive)
   is hashed.  The resulting hash value is what is signed.  The left 16
   bits of the hash are included in the Signature packet to provide a
   quick test to reject some invalid signatures.

   There are two fields consisting of Signature subpackets.  The first
   field is hashed with the rest of the signature data, while the second
   is unhashed.  The second set of subpackets is not cryptographically




Callas, et al               Standards Track                    [Page 24]

RFC 4880                 OpenPGP Message Format            November 2007


   protected by the signature and should include only advisory
   information.

   The algorithms for converting the hash function result to a signature
   are described in a section below.

5.2.3.1.  Signature Subpacket Specification

   A subpacket data set consists of zero or more Signature subpackets.
   In Signature packets, the subpacket data set is preceded by a two-
   octet scalar count of the length in octets of all the subpackets.  A
   pointer incremented by this number will skip over the subpacket data
   set.

   Each subpacket consists of a subpacket header and a body.  The header
   consists of:

     - the subpacket length (1, 2, or 5 octets),

     - the subpacket type (1 octet),

   and is followed by the subpacket-specific data.

   The length includes the type octet but not this length.  Its format
   is similar to the "new" format packet header lengths, but cannot have
   Partial Body Lengths.  That is:

       if the 1st octet <  192, then
           lengthOfLength = 1
           subpacketLen = 1st_octet

       if the 1st octet >= 192 and < 255, then
           lengthOfLength = 2
           subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

       if the 1st octet = 255, then
           lengthOfLength = 5
           subpacket length = [four-octet scalar starting at 2nd_octet]

   The value of the subpacket type octet may be:

            0 = Reserved
            1 = Reserved
            2 = Signature Creation Time
            3 = Signature Expiration Time
            4 = Exportable Certification
            5 = Trust Signature
            6 = Regular Expression



Callas, et al               Standards Track                    [Page 25]

RFC 4880                 OpenPGP Message Format            November 2007


            7 = Revocable
            8 = Reserved
            9 = Key Expiration Time
           10 = Placeholder for backward compatibility
           11 = Preferred Symmetric Algorithms
           12 = Revocation Key
           13 = Reserved
           14 = Reserved
           15 = Reserved
           16 = Issuer
           17 = Reserved
           18 = Reserved
           19 = Reserved
           20 = Notation Data
           21 = Preferred Hash Algorithms
           22 = Preferred Compression Algorithms
           23 = Key Server Preferences
           24 = Preferred Key Server
           25 = Primary User ID
           26 = Policy URI
           27 = Key Flags
           28 = Signer's User ID
           29 = Reason for Revocation
           30 = Features
           31 = Signature Target
           32 = Embedded Signature
   100 To 110 = Private or experimental

   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that is
   marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

   An evaluator may "recognize" a subpacket, but not implement it.  The
   purpose of the critical bit is to allow the signer to tell an
   evaluator that it would prefer a new, unknown feature to generate an
   error than be ignored.

   Implementations SHOULD implement the three preferred algorithm
   subpackets (11, 21, and 22), as well as the "Reason for Revocation"
   subpacket.  Note, however, that if an implementation chooses not to
   implement some of the preferences, it is required to behave in a
   polite manner to respect the wishes of those users who do implement
   these preferences.



Callas, et al               Standards Track                    [Page 26]

RFC 4880                 OpenPGP Message Format            November 2007


5.2.3.2.  Signature Subpacket Types

   A number of subpackets are currently defined.  Some subpackets apply
   to the signature itself and some are attributes of the key.
   Subpackets that are found on a self-signature are placed on a
   certification made by the key itself.  Note that a key may have more
   than one User ID, and thus may have more than one self-signature, and
   differing subpackets.

   A subpacket may be found either in the hashed or unhashed subpacket
   sections of a signature.  If a subpacket is not hashed, then the
   information in it cannot be considered definitive because it is not
   part of the signature proper.

5.2.3.3.  Notes on Self-Signatures

   A self-signature is a binding signature made by the key to which the
   signature refers.  There are three types of self-signatures, the
   certification signatures (types 0x10-0x13), the direct-key signature
   (type 0x1F), and the subkey binding signature (type 0x18).  For
   certification self-signatures, each User ID may have a self-
   signature, and thus different subpackets in those self-signatures.
   For subkey binding signatures, each subkey in fact has a self-
   signature.  Subpackets that appear in a certification self-signature
   apply to the user name, and subpackets that appear in the subkey
   self-signature apply to the subkey.  Lastly, subpackets on the
   direct-key signature apply to the entire key.

   Implementing software should interpret a self-signature's preference
   subpackets as narrowly as possible.  For example, suppose a key has
   two user names, Alice and Bob.  Suppose that Alice prefers the
   symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES.  If the
   software locates this key via Alice's name, then the preferred
   algorithm is CAST5; if software locates the key via Bob's name, then
   the preferred algorithm is IDEA.  If the key is located by Key ID,
   the algorithm of the primary User ID of the key provides the
   preferred symmetric algorithm.

   Revoking a self-signature or allowing it to expire has a semantic
   meaning that varies with the signature type.  Revoking the self-
   signature on a User ID effectively retires that user name.  The
   self-signature is a statement, "My name X is tied to my signing key
   K" and is corroborated by other users' certifications.  If another
   user revokes their certification, they are effectively saying that
   they no longer believe that name and that key are tied together.
   Similarly, if the users themselves revoke their self-signature, then
   the users no longer go by that name, no longer have that email
   address, etc.  Revoking a binding signature effectively retires that



Callas, et al               Standards Track                    [Page 27]

RFC 4880                 OpenPGP Message Format            November 2007


   subkey.  Revoking a direct-key signature cancels that signature.
   Please see the "Reason for Revocation" subpacket (Section 5.2.3.23)
   for more relevant detail.

   Since a self-signature contains important information about the key's
   use, an implementation SHOULD allow the user to rewrite the self-
   signature, and important information in it, such as preferences and
   key expiration.

   It is good practice to verify that a self-signature imported into an
   implementation doesn't advertise features that the implementation
   doesn't support, rewriting the signature as appropriate.

   An implementation that encounters multiple self-signatures on the
   same object may resolve the ambiguity in any way it sees fit, but it
   is RECOMMENDED that priority be given to the most recent self-
   signature.

5.2.3.4.  Signature Creation Time

   (4-octet time field)

   The time the signature was made.

   MUST be present in the hashed area.

5.2.3.5.  Issuer

   (8-octet Key ID)

   The OpenPGP Key ID of the key issuing the signature.

5.2.3.6.  Key Expiration Time

   (4-octet time field)

   The validity period of the key.  This is the number of seconds after
   the key creation time that the key expires.  If this is not present
   or has a value of zero, the key never expires.  This is found only on
   a self-signature.

5.2.3.7.  Preferred Symmetric Algorithms

   (array of one-octet values)

   Symmetric algorithm numbers that indicate which algorithms the key
   holder prefers to use.  The subpacket body is an ordered list of
   octets with the most preferred listed first.  It is assumed that only



Callas, et al               Standards Track                    [Page 28]

RFC 4880                 OpenPGP Message Format            November 2007


   algorithms listed are supported by the recipient's software.
   Algorithm numbers are in Section 9.  This is only found on a self-
   signature.

5.2.3.8.  Preferred Hash Algorithms

   (array of one-octet values)

   Message digest algorithm numbers that indicate which algorithms the
   key holder prefers to receive.  Like the preferred symmetric
   algorithms, the list is ordered.  Algorithm numbers are in Section 9.
   This is only found on a self-signature.

5.2.3.9.  Preferred Compression Algorithms

   (array of one-octet values)

   Compression algorithm numbers that indicate which algorithms the key
   holder prefers to use.  Like the preferred symmetric algorithms, the
   list is ordered.  Algorithm numbers are in Section 9.  If this
   subpacket is not included, ZIP is preferred.  A zero denotes that
   uncompressed data is preferred; the key holder's software might have
   no compression software in that implementation.  This is only found
   on a self-signature.

5.2.3.10.  Signature Expiration Time

   (4-octet time field)

   The validity period of the signature.  This is the number of seconds
   after the signature creation time that the signature expires.  If
   this is not present or has a value of zero, it never expires.

5.2.3.11.  Exportable Certification

   (1 octet of exportability, 0 for not, 1 for exportable)

   This subpacket denotes whether a certification signature is
   "exportable", to be used by other users than the signature's issuer.
   The packet body contains a Boolean flag indicating whether the
   signature is exportable.  If this packet is not present, the
   certification is exportable; it is equivalent to a flag containing a
   1.

   Non-exportable, or "local", certifications are signatures made by a
   user to mark a key as valid within that user's implementation only.

Callas, et al               Standards Track                    [Page 29]

RFC 4880                 OpenPGP Message Format            November 2007


   Thus, when an implementation prepares a user's copy of a key for
   transport to another user (this is the process of "exporting" the
   key), any local certification signatures are deleted from the key.

   The receiver of a transported key "imports" it, and likewise trims
   any local certifications.  In normal operation, there won't be any,
   assuming the import is performed on an exported key.  However, there
   are instances where this can reasonably happen.  For example, if an
   implementation allows keys to be imported from a key database in
   addition to an exported key, then this situation can arise.

   Some implementations do not represent the interest of a single user
   (for example, a key server).  Such implementations always trim local
   certifications from any key they handle.

5.2.3.12.  Revocable

   (1 octet of revocability, 0 for not, 1 for revocable)

   Signature's revocability status.  The packet body contains a Boolean
   flag indicating whether the signature is revocable.  Signatures that
   are not revocable have any later revocation signatures ignored.  They
   represent a commitment by the signer that he cannot revoke his
   signature for the life of his key.  If this packet is not present,
   the signature is revocable.

5.2.3.13.  Trust Signature

   (1 octet "level" (depth), 1 octet of trust amount)

   Signer asserts that the key is not only valid but also trustworthy at
   the specified level.  Level 0 has the same meaning as an ordinary
   validity signature.  Level 1 means that the signed key is asserted to
   be a valid trusted introducer, with the 2nd octet of the body
   specifying the degree of trust.  Level 2 means that the signed key is
   asserted to be trusted to issue level 1 trust signatures, i.e., that
   it is a "meta introducer".  Generally, a level n trust signature
   asserts that a key is trusted to issue level n-1 trust signatures.
   The trust amount is in a range from 0-255, interpreted such that
   values less than 120 indicate partial trust and values of 120 or
   greater indicate complete trust.  Implementations SHOULD emit values
   of 60 for partial trust and 120 for complete trust.

Callas, et al               Standards Track                    [Page 30]

RFC 4880                 OpenPGP Message Format            November 2007


5.2.3.14.  Regular Expression

   (null-terminated regular expression)

   Used in conjunction with trust Signature packets (of level > 0) to
   limit the scope of trust that is extended.  Only signatures by the
   target key on User IDs that match the regular expression in the body
   of this packet have trust extended by the trust Signature subpacket.
   The regular expression uses the same syntax as the Henry Spencer's
   "almost public domain" regular expression [REGEX] package.  A
   description of the syntax is found in Section 8 below.

5.2.3.15.  Revocation Key

   (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of
   fingerprint)

   Authorizes the specified key to issue revocation signatures for this
   key.  Class octet must have bit 0x80 set.  If the bit 0x40 is set,
   then this means that the revocation information is sensitive.  Other
   bits are for future expansion to other kinds of authorizations.  This
   is found on a self-signature.

   If the "sensitive" flag is set, the keyholder feels this subpacket
   contains private trust information that describes a real-world
   sensitive relationship.  If this flag is set, implementations SHOULD
   NOT export this signature to other users except in cases where the
   data needs to be available: when the signature is being sent to the
   designated revoker, or when it is accompanied by a revocation
   signature from that revoker.  Note that it may be appropriate to
   isolate this subpacket within a separate signature so that it is not
   combined with other subpackets that need to be exported.

5.2.3.16.  Notation Data

       (4 octets of flags, 2 octets of name length (M),
                           2 octets of value length (N),
                           M octets of name data,
                           N octets of value data)

   This subpacket describes a "notation" on the signature that the
   issuer wishes to make.  The notation has a name and a value, each of
   which are strings of octets.  There may be more than one notation in
   a signature.  Notations can be used for any extension the issuer of
   the signature cares to make.  The "flags" field holds four octets of
   flags.


Callas, et al               Standards Track                    [Page 31]

RFC 4880                 OpenPGP Message Format            November 2007


   All undefined flags MUST be zero.  Defined flags are as follows:

       First octet: 0x80 = human-readable.  This note value is text.
       Other octets: none.

   Notation names are arbitrary strings encoded in UTF-8.  They reside
   in two namespaces: The IETF namespace and the user namespace.

   The IETF namespace is registered with IANA.  These names MUST NOT
   contain the "@" character (0x40).  This is a tag for the user
   namespace.

   Names in the user namespace consist of a UTF-8 string tag followed by
   "@" followed by a DNS domain name.  Note that the tag MUST NOT
   contain an "@" character.  For example, the "sample" tag used by
   Example Corporation could be "sample@example.com".

   Names in a user space are owned and controlled by the owners of that
   domain.  Obviously, it's bad form to create a new name in a DNS space
   that you don't own.

   Since the user namespace is in the form of an email address,
   implementers MAY wish to arrange for that address to reach a person
   who can be consulted about the use of the named tag.  Note that due
   to UTF-8 encoding, not all valid user space name tags are valid email
   addresses.

   If there is a critical notation, the criticality applies to that
   specific notation and not to notations in general.

5.2.3.17.  Key Server Preferences

   (N octets of flags)

   This is a list of one-bit flags that indicate preferences that the
   key holder has about how the key is handled on a key server.  All
   undefined flags MUST be zero.

   First octet: 0x80 = No-modify
       the key holder requests that this key only be modified or updated
       by the key holder or an administrator of the key server.

   This is found only on a self-signature.

Callas, et al               Standards Track                    [Page 32]

RFC 4880                 OpenPGP Message Format            November 2007


5.2.3.18.  Preferred Key Server

   (String)

   This is a URI of a key server that the key holder prefers be used for
   updates.  Note that keys with multiple User IDs can have a preferred
   key server for each User ID.  Note also that since this is a URI, the
   key server can actually be a copy of the key retrieved by ftp, http,
   finger, etc.

5.2.3.19.  Primary User ID

   (1 octet, Boolean)

   This is a flag in a User ID's self-signature that states whether this
   User ID is the main User ID for this key.  It is reasonable for an
   implementation to resolve ambiguities in preferences, etc. by
   referring to the primary User ID.  If this flag is absent, its value
   is zero.  If more than one User ID in a key is marked as primary, the
   implementation may resolve the ambiguity in any way it sees fit, but
   it is RECOMMENDED that priority be given to the User ID with the most
   recent self-signature.

   When appearing on a self-signature on a User ID packet, this
   subpacket applies only to User ID packets.  When appearing on a
   self-signature on a User Attribute packet, this subpacket applies
   only to User Attribute packets.  That is to say, there are two
   different and independent "primaries" -- one for User IDs, and one
   for User Attributes.

5.2.3.20.  Policy URI

   (String)

   This subpacket contains a URI of a document that describes the policy
   under which the signature was issued.

5.2.3.21.  Key Flags

   (N octets of flags)

   This subpacket contains a list of binary flags that hold information
   about a key.  It is a string of octets, and an implementation MUST
   NOT assume a fixed size.  This is so it can grow over time.  If a
   list is shorter than an implementation expects, the unstated flags
   are considered to be zero.  The defined flags are as follows:





Callas, et al               Standards Track                    [Page 33]

RFC 4880                 OpenPGP Message Format            November 2007


       First octet:

       0x01 - This key may be used to certify other keys.

       0x02 - This key may be used to sign data.

       0x04 - This key may be used to encrypt communications.

       0x08 - This key may be used to encrypt storage.

       0x10 - The private component of this key may have been split
              by a secret-sharing mechanism.

       0x20 - This key may be used for authentication.

       0x80 - The private component of this key may be in the
              possession of more than one person.

   Usage notes:

   The flags in this packet may appear in self-signatures or in
   certification signatures.  They mean different things depending on
   who is making the statement -- for example, a certification signature
   that has the "sign data" flag is stating that the certification is
   for that use.  On the other hand, the "communications encryption"
   flag in a self-signature is stating a preference that a given key be
   used for communications.  Note however, that it is a thorny issue to
   determine what is "communications" and what is "storage".  This
   decision is left wholly up to the implementation; the authors of this
   document do not claim any special wisdom on the issue and realize
   that accepted opinion may change.

   The "split key" (0x10) and "group key" (0x80) flags are placed on a
   self-signature only; they are meaningless on a certification
   signature.  They SHOULD be placed only on a direct-key signature
   (type 0x1F) or a subkey signature (type 0x18), one that refers to the
   key the flag applies to.

5.2.3.22.  Signer's User ID

   (String)

   This subpacket allows a keyholder to state which User ID is
   responsible for the signing.  Many keyholders use a single key for
   different purposes, such as business communications as well as
   personal communications.  This subpacket allows such a keyholder to
   state which of their roles is making a signature.




Callas, et al               Standards Track                    [Page 34]

RFC 4880                 OpenPGP Message Format            November 2007


   This subpacket is not appropriate to use to refer to a User Attribute
   packet.

5.2.3.23.  Reason for Revocation

   (1 octet of revocation code, N octets of reason string)

   This subpacket is used only in key revocation and certification
   revocation signatures.  It describes the reason why the key or
   certificate was revoked.

   The first octet contains a machine-readable code that denotes the
   reason for the revocation:

        0  - No reason specified (key revocations or cert revocations)
        1  - Key is superseded (key revocations)
        2  - Key material has been compromised (key revocations)
        3  - Key is retired and no longer used (key revocations)
        32 - User ID information is no longer valid (cert revocations)
   100-110 - Private Use

   Following the revocation code is a string of octets that gives
   information about the Reason for Revocation in human-readable form
   (UTF-8).  The string may be null, that is, of zero length.  The
   length of the subpacket is the length of the reason string plus one.
   An implementation SHOULD implement this subpacket, include it in all
   revocation signatures, and interpret revocations appropriately.
   There are important semantic differences between the reasons, and
   there are thus important reasons for revoking signatures.

   If a key has been revoked because of a compromise, all signatures
   created by that key are suspect.  However, if it was merely
   superseded or retired, old signatures are still valid.  If the
   revoked signature is the self-signature for certifying a User ID, a
   revocation denotes that that user name is no longer in use.  Such a
   revocation SHOULD include a 0x20 code.

   Note that any signature may be revoked, including a certification on
   some other person's key.  There are many good reasons for revoking a
   certification signature, such as the case where the keyholder leaves
   the employ of a business with an email address.  A revoked
   certification is no longer a part of validity calculations.


Callas, et al               Standards Track                    [Page 35]

RFC 4880                 OpenPGP Message Format            November 2007


5.2.3.24.  Features

   (N octets of flags)

   The Features subpacket denotes which advanced OpenPGP features a
   user's implementation supports.  This is so that as features are
   added to OpenPGP that cannot be backwards-compatible, a user can
   state that they can use that feature.  The flags are single bits that
   indicate that a given feature is supported.

   This subpacket is similar to a preferences subpacket, and only
   appears in a self-signature.

   An implementation SHOULD NOT use a feature listed when sending to a
   user who does not state that they can use it.

   Defined features are as follows:

       First octet:

       0x01 - Modification Detection (packets 18 and 19)

   If an implementation implements any of the defined features, it
   SHOULD implement the Features subpacket, too.

   An implementation may freely infer features from other suitable
   implementation-dependent mechanisms.

5.2.3.25.  Signature Target

   (1 octet public-key algorithm, 1 octet hash algorithm, N octets hash)

   This subpacket identifies a specific target signature to which a
   signature refers.  For revocation signatures, this subpacket
   provides explicit designation of which signature is being revoked.
   For a third-party or timestamp signature, this designates what
   signature is signed.  All arguments are an identifier of that target
   signature.

   The N octets of hash data MUST be the size of the hash of the
   signature.  For example, a target signature with a SHA-1 hash MUST
   have 20 octets of hash data.


Callas, et al               Standards Track                    [Page 36]

RFC 4880                 OpenPGP Message Format            November 2007


5.2.3.26.  Embedded Signature

   (1 signature packet body)

   This subpacket contains a complete Signature packet body as
   specified in Section 5.2 above.  It is useful when one signature
   needs to refer to, or be incorporated in, another signature.

5.2.4.  Computing Signatures

   All signatures are formed by producing a hash over the signature
   data, and then using the resulting hash in the signature algorithm.

   For binary document signatures (type 0x00), the document data is
   hashed directly.  For text document signatures (type 0x01), the
   document is canonicalized by converting line endings to <CR><LF>,
   and the resulting data is hashed.

   When a signature is made over a key, the hash data starts with the
   octet 0x99, followed by a two-octet length of the key, and then body
   of the key packet.  (Note that this is an old-style packet header for
   a key packet with two-octet length.)  A subkey binding signature
   (type 0x18) or primary key binding signature (type 0x19) then hashes
   the subkey using the same format as the main key (also using 0x99 as
   the first octet).  Key revocation signatures (types 0x20 and 0x28)
   hash only the key being revoked.

   A certification signature (type 0x10 through 0x13) hashes the User
   ID being bound to the key into the hash context after the above
   data.  A V3 certification hashes the contents of the User ID or
   attribute packet packet, without any header.  A V4 certification
   hashes the constant 0xB4 for User ID certifications or the constant
   0xD1 for User Attribute certifications, followed by a four-octet
   number giving the length of the User ID or User Attribute data, and
   then the User ID or User Attribute data.

   When a signature is made over a Signature packet (type 0x50), the
   hash data starts with the octet 0x88, followed by the four-octet
   length of the signature, and then the body of the Signature packet.
   (Note that this is an old-style packet header for a Signature packet
   with the length-of-length set to zero.)  The unhashed subpacket data
   of the Signature packet being hashed is not included in the hash, and
   the unhashed subpacket data length value is set to zero.

   Once the data body is hashed, then a trailer is hashed.  A V3
   signature hashes five octets of the packet body, starting from the
   signature type field.  This data is the signature type, followed by
   the four-octet signature time.  A V4 signature hashes the packet body



Callas, et al               Standards Track                    [Page 37]

RFC 4880                 OpenPGP Message Format            November 2007


   starting from its first field, the version number, through the end
   of the hashed subpacket data.  Thus, the fields hashed are the
   signature version, the signature type, the public-key algorithm, the
   hash algorithm, the hashed subpacket length, and the hashed
   subpacket body.

   V4 signatures also hash in a final trailer of six octets: the
   version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet,
   big-endian number that is the length of the hashed data from the
   Signature packet (note that this number does not include these final
   six octets).

   After all this has been hashed in a single hash context, the
   resulting hash field is used in the signature algorithm and placed
   at the end of the Signature packet.

5.2.4.1.  Subpacket Hints

   It is certainly possible for a signature to contain conflicting
   information in subpackets.  For example, a signature may contain
   multiple copies of a preference or multiple expiration times.  In
   most cases, an implementation SHOULD use the last subpacket in the
   signature, but MAY use any conflict resolution scheme that makes
   more sense.  Please note that we are intentionally leaving conflict
   resolution to the implementer; most conflicts are simply syntax
   errors, and the wishy-washy language here allows a receiver to be
   generous in what they accept, while putting pressure on a creator to
   be stingy in what they generate.

   Some apparent conflicts may actually make sense -- for example,
   suppose a keyholder has a V3 key and a V4 key that share the same
   RSA key material.  Either of these keys can verify a signature
   created by the other, and it may be reasonable for a signature to
   contain an issuer subpacket for each key, as a way of explicitly
   tying those keys to the signature.

5.3.  Symmetric-Key Encrypted Session Key Packets (Tag 3)

   The Symmetric-Key Encrypted Session Key packet holds the
   symmetric-key encryption of a session key used to encrypt a message.
   Zero or more Public-Key Encrypted Session Key packets and/or
   Symmetric-Key Encrypted Session Key packets may precede a
   Symmetrically Encrypted Data packet that holds an encrypted message.
   The message is encrypted with a session key, and the session key is
   itself encrypted and stored in the Encrypted Session Key packet or
   the Symmetric-Key Encrypted Session Key packet.



Callas, et al               Standards Track                    [Page 38]

RFC 4880                 OpenPGP Message Format            November 2007


   If the Symmetrically Encrypted Data packet is preceded by one or
   more Symmetric-Key Encrypted Session Key packets, each specifies a
   passphrase that may be used to decrypt the message.  This allows a
   message to be encrypted to a number of public keys, and also to one
   or more passphrases.  This packet type is new and is not generated
   by PGP 2.x or PGP 5.0.

   The body of this packet consists of:

     - A one-octet version number.  The only currently defined version
       is 4.

     - A one-octet number describing the symmetric algorithm used.

     - A string-to-key (S2K) specifier, length as defined above.

     - Optionally, the encrypted session key itself, which is decrypted
       with the string-to-key object.

   If the encrypted session key is not present (which can be detected
   on the basis of packet length and S2K specifier size), then the S2K
   algorithm applied to the passphrase produces the session key for
   decrypting the file, using the symmetric cipher algorithm from the
   Symmetric-Key Encrypted Session Key packet.

   If the encrypted session key is present, the result of applying the
   S2K algorithm to the passphrase is used to decrypt just that
   encrypted session key field, using CFB mode with an IV of all zeros.
   The decryption result consists of a one-octet algorithm identifier
   that specifies the symmetric-key encryption algorithm used to
   encrypt the following Symmetrically Encrypted Data packet, followed
   by the session key octets themselves.

   Note: because an all-zero IV is used for this decryption, the S2K
   specifier MUST use a salt value, either a Salted S2K or an
   Iterated-Salted S2K.  The salt value will ensure that the decryption
   key is not repeated even if the passphrase is reused.

5.4.  One-Pass Signature Packets (Tag 4)

   The One-Pass Signature packet precedes the signed data and contains
   enough information to allow the receiver to begin calculating any
   hashes needed to verify the signature.  It allows the Signature
   packet to be placed at the end of the message, so that the signer
   can compute the entire signed message in one pass.

   A One-Pass Signature does not interoperate with PGP 2.6.x or
   earlier.



Callas, et al               Standards Track                    [Page 39]

RFC 4880                 OpenPGP Message Format            November 2007


   The body of this packet consists of:

     - A one-octet version number.  The current version is 3.

     - A one-octet signature type.  Signature types are described in
       Section 5.2.1.

     - A one-octet number describing the hash algorithm used.

     - A one-octet number describing the public-key algorithm used.

     - An eight-octet number holding the Key ID of the signing key.

     - A one-octet number holding a flag showing whether the signature
       is nested.  A zero value indicates that the next packet is
       another One-Pass Signature packet that describes another
       signature to be applied to the same message data.

   Note that if a message contains more than one one-pass signature,
   then the Signature packets bracket the message; that is, the first
   Signature packet after the message corresponds to the last one-pass
   packet and the final Signature packet corresponds to the first
   one-pass packet.

5.5.  Key Material Packet

   A key material packet contains all the information about a public or
   private key.  There are four variants of this packet type, and two
   major versions.  Consequently, this section is complex.

5.5.1.  Key Packet Variants

5.5.1.1.  Public-Key Packet (Tag 6)

   A Public-Key packet starts a series of packets that forms an OpenPGP
   key (sometimes called an OpenPGP certificate).

5.5.1.2.  Public-Subkey Packet (Tag 14)

   A Public-Subkey packet (tag 14) has exactly the same format as a
   Public-Key packet, but denotes a subkey.  One or more subkeys may be
   associated with a top-level key.  By convention, the top-level key
   provides signature services, and the subkeys provide encryption
   services.

   Note: in PGP 2.6.x, tag 14 was intended to indicate a comment
   packet.  This tag was selected for reuse because no previous version
   of PGP ever emitted comment packets but they did properly ignore



Callas, et al               Standards Track                    [Page 40]

RFC 4880                 OpenPGP Message Format            November 2007


   them.  Public-Subkey packets are ignored by PGP 2.6.x and do not
   cause it to fail, providing a limited degree of backward
   compatibility.

5.5.1.3.  Secret-Key Packet (Tag 5)

   A Secret-Key packet contains all the information that is found in a
   Public-Key packet, including the public-key material, but also
   includes the secret-key material after all the public-key fields.

5.5.1.4.  Secret-Subkey Packet (Tag 7)

   A Secret-Subkey packet (tag 7) is the subkey analog of the Secret
   Key packet and has exactly the same format.

5.5.2.  Public-Key Packet Formats

   There are two versions of key-material packets.  Version 3 packets
   were first generated by PGP 2.6.  Version 4 keys first appeared in
   PGP 5.0 and are the preferred key version for OpenPGP.

   OpenPGP implementations MUST create keys with version 4 format.  V3
   keys are deprecated; an implementation MUST NOT generate a V3 key,
   but MAY accept it.

   A version 3 public key or public-subkey packet contains:

     - A one-octet version number (3).

     - A four-octet number denoting the time that the key was created.

     - A two-octet number denoting the time in days that this key is
       valid.  If this number is zero, then it does not expire.

     - A one-octet number denoting the public-key algorithm of this key.

     - A series of multiprecision integers comprising the key material:

           - a multiprecision integer (MPI) of RSA public modulus n;

           - an MPI of RSA public encryption exponent e.

   V3 keys are deprecated.  They contain three weaknesses.  First, it is
   relatively easy to construct a V3 key that has the same Key ID as any
   other key because the Key ID is simply the low 64 bits of the public
   modulus.  Secondly, because the fingerprint of a V3 key hashes the
   key material, but not its length, there is an increased opportunity
   for fingerprint collisions.  Third, there are weaknesses in the MD5



Callas, et al               Standards Track                    [Page 41]

RFC 4880                 OpenPGP Message Format            November 2007


   hash algorithm that make developers prefer other algorithms.  See
   below for a fuller discussion of Key IDs and fingerprints.

   V2 keys are identical to the deprecated V3 keys except for the
   version number.  An implementation MUST NOT generate them and MAY
   accept or reject them as it sees fit.

   The version 4 format is similar to the version 3 format except for
   the absence of a validity period.  This has been moved to the
   Signature packet.  In addition, fingerprints of version 4 keys are
   calculated differently from version 3 keys, as described in the
   section "Enhanced Key Formats".

   A version 4 packet contains:

     - A one-octet version number (4).

     - A four-octet number denoting the time that the key was created.

     - A one-octet number denoting the public-key algorithm of this key.

     - A series of multiprecision integers comprising the key material.
       This algorithm-specific portion is:

       Algorithm-Specific Fields for RSA public keys:

         - multiprecision integer (MPI) of RSA public modulus n;

         - MPI of RSA public encryption exponent e.

       Algorithm-Specific Fields for DSA public keys:

         - MPI of DSA prime p;

         - MPI of DSA group order q (q is a prime divisor of p-1);

         - MPI of DSA group generator g;

         - MPI of DSA public-key value y (= g**x mod p where x
           is secret).

       Algorithm-Specific Fields for Elgamal public keys:

         - MPI of Elgamal prime p;

         - MPI of Elgamal group generator g;





Callas, et al               Standards Track                    [Page 42]

RFC 4880                 OpenPGP Message Format            November 2007


         - MPI of Elgamal public key value y (= g**x mod p where x
           is secret).

5.5.3.  Secret-Key Packet Formats

   The Secret-Key and Secret-Subkey packets contain all the data of the
   Public-Key and Public-Subkey packets, with additional algorithm-
   specific secret-key data appended, usually in encrypted form.

   The packet contains:

     - A Public-Key or Public-Subkey packet, as described above.

     - One octet indicating string-to-key usage conventions.  Zero
       indicates that the secret-key data is not encrypted.  255 or 254
       indicates that a string-to-key specifier is being given.  Any
       other value is a symmetric-key encryption algorithm identifier.

     - [Optional] If string-to-key usage octet was 255 or 254, a one-
       octet symmetric encryption algorithm.

     - [Optional] If string-to-key usage octet was 255 or 254, a
       string-to-key specifier.  The length of the string-to-key
       specifier is implied by its type, as described above.

     - [Optional] If secret data is encrypted (string-to-key usage octet
       not zero), an Initial Vector (IV) of the same length as the
       cipher's block size.

     - Plain or encrypted multiprecision integers comprising the secret
       key data.  These algorithm-specific fields are as described
       below.

     - If the string-to-key usage octet is zero or 255, then a two-octet
       checksum of the plaintext of the algorithm-specific portion (sum
       of all octets, mod 65536).  If the string-to-key usage octet was
       254, then a 20-octet SHA-1 hash of the plaintext of the
       algorithm-specific portion.  This checksum or hash is encrypted
       together with the algorithm-specific fields (if string-to-key
       usage octet is not zero).  Note that for all other values, a
       two-octet checksum is required.

       Algorithm-Specific Fields for RSA secret keys:

       - multiprecision integer (MPI) of RSA secret exponent d.

       - MPI of RSA secret prime value p.




Callas, et al               Standards Track                    [Page 43]

RFC 4880                 OpenPGP Message Format            November 2007


       - MPI of RSA secret prime value q (p < q).

       - MPI of u, the multiplicative inverse of p, mod q.

       Algorithm-Specific Fields for DSA secret keys:

       - MPI of DSA secret exponent x.

       Algorithm-Specific Fields for Elgamal secret keys:

       - MPI of Elgamal secret exponent x.

   Secret MPI values can be encrypted using a passphrase.  If a string-
   to-key specifier is given, that describes the algorithm for
   converting the passphrase to a key, else a simple MD5 hash of the
   passphrase is used.  Implementations MUST use a string-to-key
   specifier; the simple hash is for backward compatibility and is
   deprecated, though implementations MAY continue to use existing
   private keys in the old format.  The cipher for encrypting the MPIs
   is specified in the Secret-Key packet.

   Encryption/decryption of the secret data is done in CFB mode using
   the key created from the passphrase and the Initial Vector from the
   packet.  A different mode is used with V3 keys (which are only RSA)
   than with other key formats.  With V3 keys, the MPI bit count prefix
   (i.e., the first two octets) is not encrypted.  Only the MPI non-
   prefix data is encrypted.  Furthermore, the CFB state is
   resynchronized at the beginning of each new MPI value, so that the
   CFB block boundary is aligned with the start of the MPI data.

   With V4 keys, a simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the MPI bitcount prefix.

   The two-octet checksum that follows the algorithm-specific portion is
   the algebraic sum, mod 65536, of the plaintext of all the algorithm-
   specific octets (including MPI prefix and data).  With V3 keys, the
   checksum is stored in the clear.  With V4 keys, the checksum is
   encrypted like the algorithm-specific data.  This value is used to
   check that the passphrase was correct.  However, this checksum is
   deprecated; an implementation SHOULD NOT use it, but should rather
   use the SHA-1 hash denoted with a usage octet of 254.  The reason for
   this is that there are some attacks that involve undetectably
   modifying the secret key.


Callas, et al               Standards Track                    [Page 44]

RFC 4880                 OpenPGP Message Format            November 2007


5.6.  Compressed Data Packet (Tag 8)

   The Compressed Data packet contains compressed data.  Typically, this
   packet is found as the contents of an encrypted packet, or following
   a Signature or One-Pass Signature packet, and contains a literal data
   packet.

   The body of this packet consists of:

     - One octet that gives the algorithm used to compress the packet.

     - Compressed data, which makes up the remainder of the packet.

   A Compressed Data Packet's body contains an block that compresses
   some set of packets.  See section "Packet Composition" for details on
   how messages are formed.

   ZIP-compressed packets are compressed with raw RFC 1951 [RFC1951]
   DEFLATE blocks.  Note that PGP V2.6 uses 13 bits of compression.  If
   an implementation uses more bits of compression, PGP V2.6 cannot
   decompress it.

   ZLIB-compressed packets are compressed with RFC 1950 [RFC1950] ZLIB-
   style blocks.

   BZip2-compressed packets are compressed using the BZip2 [BZ2]
   algorithm.

5.7.  Symmetrically Encrypted Data Packet (Tag 9)

   The Symmetrically Encrypted Data packet contains data encrypted with
   a symmetric-key algorithm.  When it has been decrypted, it contains
   other packets (usually a literal data packet or compressed data
   packet, but in theory other Symmetrically Encrypted Data packets or
   sequences of packets that form whole OpenPGP messages).

   The body of this packet consists of:

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in OpenPGP's variant of Cipher Feedback (CFB) mode.

   The symmetric cipher used may be specified in a Public-Key or
   Symmetric-Key Encrypted Session Key packet that precedes the
   Symmetrically Encrypted Data packet.  In that case, the cipher
   algorithm octet is prefixed to the session key before it is
   encrypted.  If no packets of these types precede the encrypted data,
   the IDEA algorithm is used with the session key calculated as the MD5
   hash of the passphrase, though this use is deprecated.



Callas, et al               Standards Track                    [Page 45]

RFC 4880                 OpenPGP Message Format            November 2007


   The data is encrypted in CFB mode, with a CFB shift size equal to the
   cipher's block size.  The Initial Vector (IV) is specified as all
   zeros.  Instead of using an IV, OpenPGP prefixes a string of length
   equal to the block size of the cipher plus two to the data before it
   is encrypted.  The first block-size octets (for example, 8 octets for
   a 64-bit block length) are random, and the following two octets are
   copies of the last two octets of the IV.  For example, in an 8-octet
   block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of
   octet 8.  In a cipher of length 16, octet 17 is a repeat of octet 15
   and octet 18 is a repeat of octet 16.  As a pedantic clarification,
   in both these examples, we consider the first octet to be numbered 1.

   After encrypting the first block-size-plus-two octets, the CFB state
   is resynchronized.  The last block-size octets of ciphertext are
   passed through the cipher and the block boundary is reset.

   The repetition of 16 bits in the random data prefixed to the message
   allows the receiver to immediately check whether the session key is
   incorrect.  See the "Security Considerations" section for hints on
   the proper use of this "quick check".

5.8.  Marker Packet (Obsolete Literal Packet) (Tag 10)

   An experimental version of PGP used this packet as the Literal
   packet, but no released version of PGP generated Literal packets with
   this tag.  With PGP 5.x, this packet has been reassigned and is
   reserved for use as the Marker packet.

   The body of this packet consists of:

     - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).

   Such a packet MUST be ignored when received.  It may be placed at the
   beginning of a message that uses features not available in PGP 2.6.x
   in order to cause that version to report that newer software is
   necessary to process the message.

5.9.  Literal Data Packet (Tag 11)

   A Literal Data packet contains the body of a message; data that is
   not to be further interpreted.

   The body of this packet consists of:

     - A one-octet field that describes how the data is formatted.



Callas, et al               Standards Track                    [Page 46]

RFC 4880                 OpenPGP Message Format            November 2007


   If it is a 'b' (0x62), then the Literal packet contains binary data.
   If it is a 't' (0x74), then it contains text data, and thus may need
   line ends converted to local form, or other text-mode changes.  The
   tag 'u' (0x75) means the same as 't', but also indicates that
   implementation believes that the literal data contains UTF-8 text.

   Early versions of PGP also defined a value of 'l' as a 'local' mode
   for machine-local conversions.  RFC 1991 [RFC1991] incorrectly stated
   this local mode flag as '1' (ASCII numeral one).  Both of these local
   modes are deprecated.

     - File name as a string (one-octet length, followed by a file
       name).  This may be a zero-length string.  Commonly, if the
       source of the encrypted data is a file, this will be the name of
       the encrypted file.  An implementation MAY consider the file name
       in the Literal packet to be a more authoritative name than the
       actual file name.

   If the special name "_CONSOLE" is used, the message is considered to
   be "for your eyes only".  This advises that the message data is
   unusually sensitive, and the receiving program should process it more
   carefully, perhaps avoiding storing the received data to disk, for
   example.

     - A four-octet number that indicates a date associated with the
       literal data.  Commonly, the date might be the modification date
       of a file, or the time the packet was created, or a zero that
       indicates no specific time.

     - The remainder of the packet is literal data.

       Text data is stored with <CR><LF> text endings (i.e., network-
       normal line endings).  These should be converted to native line
       endings by the receiving software.

5.10.  Trust Packet (Tag 12)

   The Trust packet is used only within keyrings and is not normally
   exported.  Trust packets contain data that record the user's
   specifications of which key holders are trustworthy introducers,
   along with other information that implementing software uses for
   trust information.  The format of Trust packets is defined by a given
   implementation.

   Trust packets SHOULD NOT be emitted to output streams that are
   transferred to other users, and they SHOULD be ignored on any input
   other than local keyring files.




Callas, et al               Standards Track                    [Page 47]

RFC 4880                 OpenPGP Message Format            November 2007


5.11.  User ID Packet (Tag 13)

   A User ID packet consists of UTF-8 text that is intended to represent
   the name and email address of the key holder.  By convention, it
   includes an RFC 2822 [RFC2822] mail name-addr, but there are no
   restrictions on its content.  The packet length in the header
   specifies the length of the User ID.

5.12.  User Attribute Packet (Tag 17)

   The User Attribute packet is a variation of the User ID packet.  It
   is capable of storing more types of data than the User ID packet,
   which is limited to text.  Like the User ID packet, a User Attribute
   packet may be certified by the key owner ("self-signed") or any other
   key owner who cares to certify it.  Except as noted, a User Attribute
   packet may be used anywhere that a User ID packet may be used.

   While User Attribute packets are not a required part of the OpenPGP
   standard, implementations SHOULD provide at least enough
   compatibility to properly handle a certification signature on the
   User Attribute packet.  A simple way to do this is by treating the
   User Attribute packet as a User ID packet with opaque contents, but
   an implementation may use any method desired.

   The User Attribute packet is made up of one or more attribute
   subpackets.  Each subpacket consists of a subpacket header and a
   body.  The header consists of:

     - the subpacket length (1, 2, or 5 octets)

     - the subpacket type (1 octet)

   and is followed by the subpacket specific data.

   The only currently defined subpacket type is 1, signifying an image.
   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.  Subpacket types 100 through 110 are reserved for
   private or experimental use.

5.12.1.  The Image Attribute Subpacket

   The Image Attribute subpacket is used to encode an image, presumably
   (but not required to be) that of the key owner.

   The Image Attribute subpacket begins with an image header.  The first
   two octets of the image header contain the length of the image
   header.  Note that unlike other multi-octet numerical values in this
   document, due to a historical accident this value is encoded as a



Callas, et al               Standards Track                    [Page 48]

RFC 4880                 OpenPGP Message Format            November 2007


   little-endian number.  The image header length is followed by a
   single octet for the image header version.  The only currently
   defined version of the image header is 1, which is a 16-octet image
   header.  The first three octets of a version 1 image header are thus
   0x10, 0x00, 0x01.

   The fourth octet of a version 1 image header designates the encoding
   format of the image.  The only currently defined encoding format is
   the value 1 to indicate JPEG.  Image format types 100 through 110 are
   reserved for private or experimental use.  The rest of the version 1
   image header is made up of 12 reserved octets, all of which MUST be
   set to 0.

   The rest of the image subpacket contains the image itself.  As the
   only currently defined image type is JPEG, the image is encoded in
   the JPEG File Interchange Format (JFIF), a standard file format for
   JPEG images [JFIF].

   An implementation MAY try to determine the type of an image by
   examination of the image data if it is unable to handle a particular
   version of the image header or if a specified encoding format value
   is not recognized.

5.13.  Sym. Encrypted Integrity Protected Data Packet (Tag 18)

   The Symmetrically Encrypted Integrity Protected Data packet is a
   variant of the Symmetrically Encrypted Data packet.  It is a new
   feature created for OpenPGP that addresses the problem of detecting a
   modification to encrypted data.  It is used in combination with a
   Modification Detection Code packet.

   There is a corresponding feature in the features Signature subpacket
   that denotes that an implementation can properly use this packet
   type.  An implementation MUST support decrypting these packets and
   SHOULD prefer generating them to the older Symmetrically Encrypted
   Data packet when possible.  Since this data packet protects against
   modification attacks, this standard encourages its proliferation.
   While blanket adoption of this data packet would create
   interoperability problems, rapid adoption is nevertheless important.
   An implementation SHOULD specifically denote support for this packet,
   but it MAY infer it from other mechanisms.

   For example, an implementation might infer from the use of a cipher
   such as Advanced Encryption Standard (AES) or Twofish that a user
   supports this feature.  It might place in the unhashed portion of
   another user's key signature a Features subpacket.  It might also
   present a user with an opportunity to regenerate their own self-
   signature with a Features subpacket.



Callas, et al               Standards Track                    [Page 49]

RFC 4880                 OpenPGP Message Format            November 2007


   This packet contains data encrypted with a symmetric-key algorithm
   and protected against modification by the SHA-1 hash algorithm.  When
   it has been decrypted, it will typically contain other packets (often
   a Literal Data packet or Compressed Data packet).  The last decrypted
   packet in this packet's payload MUST be a Modification Detection Code
   packet.

   The body of this packet consists of:

     - A one-octet version number.  The only currently defined value is
       1.

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in Cipher Feedback mode with shift amount equal to the
       block size of the cipher (CFB-n where n is the block size).

   The symmetric cipher used MUST be specified in a Public-Key or
   Symmetric-Key Encrypted Session Key packet that precedes the
   Symmetrically Encrypted Data packet.  In either case, the cipher
   algorithm octet is prefixed to the session key before it is
   encrypted.

   The data is encrypted in CFB mode, with a CFB shift size equal to the
   cipher's block size.  The Initial Vector (IV) is specified as all
   zeros.  Instead of using an IV, OpenPGP prefixes an octet string to
   the data before it is encrypted.  The length of the octet string
   equals the block size of the cipher in octets, plus two.  The first
   octets in the group, of length equal to the block size of the cipher,
   are random; the last two octets are each copies of their 2nd
   preceding octet.  For example, with a cipher whose block size is 128
   bits or 16 octets, the prefix data will contain 16 random octets,
   then two more octets, which are copies of the 15th and 16th octets,
   respectively.  Unlike the Symmetrically Encrypted Data Packet, no
   special CFB resynchronization is done after encrypting this prefix
   data.  See "OpenPGP CFB Mode" below for more details.

   The repetition of 16 bits in the random data prefixed to the message
   allows the receiver to immediately check whether the session key is
   incorrect.

   The plaintext of the data to be encrypted is passed through the SHA-1
   hash function, and the result of the hash is appended to the
   plaintext in a Modification Detection Code packet.  The input to the
   hash function includes the prefix data described above; it includes
   all of the plaintext, and then also includes two octets of values
   0xD3, 0x14.  These represent the encoding of a Modification Detection
   Code packet tag and length field of 20 octets.




Callas, et al               Standards Track                    [Page 50]

RFC 4880                 OpenPGP Message Format            November 2007


   The resulting hash value is stored in a Modification Detection Code
   (MDC) packet, which MUST use the two octet encoding just given to
   represent its tag and length field.  The body of the MDC packet is
   the 20-octet output of the SHA-1 hash.

   The Modification Detection Code packet is appended to the plaintext
   and encrypted along with the plaintext using the same CFB context.

   During decryption, the plaintext data should be hashed with SHA-1,
   including the prefix data as well as the packet tag and length field
   of the Modification Detection Code packet.  The body of the MDC
   packet, upon decryption, is compared with the result of the SHA-1
   hash.

   Any failure of the MDC indicates that the message has been modified
   and MUST be treated as a security problem.  Failures include a
   difference in the hash values, but also the absence of an MDC packet,
   or an MDC packet in any position other than the end of the plaintext.
   Any failure SHOULD be reported to the user.

   Note: future designs of new versions of this packet should consider
   rollback attacks since it will be possible for an attacker to change
   the version back to 1.

      NON-NORMATIVE EXPLANATION

      The MDC system, as packets 18 and 19 are called, were created to
      provide an integrity mechanism that is less strong than a
      signature, yet stronger than bare CFB encryption.

      It is a limitation of CFB encryption that damage to the ciphertext
      will corrupt the affected cipher blocks and the block following.
      Additionally, if data is removed from the end of a CFB-encrypted
      block, that removal is undetectable.  (Note also that CBC mode has
      a similar limitation, but data removed from the front of the block
      is undetectable.)

      The obvious way to protect or authenticate an encrypted block is
      to digitally sign it.  However, many people do not wish to
      habitually sign data, for a large number of reasons beyond the
      scope of this document.  Suffice it to say that many people
      consider properties such as deniability to be as valuable as
      integrity.

      OpenPGP addresses this desire to have more security than raw
      encryption and yet preserve deniability with the MDC system.  An
      MDC is intentionally not a MAC.  Its name was not selected by
      accident.  It is analogous to a checksum.



Callas, et al               Standards Track                    [Page 51]

RFC 4880                 OpenPGP Message Format            November 2007


      Despite the fact that it is a relatively modest system, it has
      proved itself in the real world.  It is an effective defense to
      several attacks that have surfaced since it has been created.  It
      has met its modest goals admirably.

      Consequently, because it is a modest security system, it has
      modest requirements on the hash function(s) it employs.  It does
      not rely on a hash function being collision-free, it relies on a
      hash function being one-way.  If a forger, Frank, wishes to send
      Alice a (digitally) unsigned message that says, "I've always
      secretly loved you, signed Bob", it is far easier for him to
      construct a new message than it is to modify anything intercepted
      from Bob.  (Note also that if Bob wishes to communicate secretly
      with Alice, but without authentication or identification and with
      a threat model that includes forgers, he has a problem that
      transcends mere cryptography.)

      Note also that unlike nearly every other OpenPGP subsystem, there
      are no parameters in the MDC system.  It hard-defines SHA-1 as its
      hash function.  This is not an accident.  It is an intentional
      choice to avoid downgrade and cross-grade attacks while making a
      simple, fast system.  (A downgrade attack would be an attack that
      replaced SHA-256 with SHA-1, for example.  A cross-grade attack
      would replace SHA-1 with another 160-bit hash, such as RIPE-
      MD/160, for example.)

      However, given the present state of hash function cryptanalysis
      and cryptography, it may be desirable to upgrade the MDC system to
      a new hash function.  See Section 13.11 in the "IANA
      Considerations" for guidance.

5.14.  Modification Detection Code Packet (Tag 19)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data, which is used to detect message modification.  It is
   only used with a Symmetrically Encrypted Integrity Protected Data
   packet.  The Modification Detection Code packet MUST be the last
   packet in the plaintext data that is encrypted in the Symmetrically
   Encrypted Integrity Protected Data packet, and MUST appear in no
   other place.

   A Modification Detection Code packet MUST have a length of 20 octets.



Callas, et al               Standards Track                    [Page 52]

RFC 4880                 OpenPGP Message Format            November 2007


   The body of this packet consists of:

     - A 20-octet SHA-1 hash of the preceding plaintext data of the
       Symmetrically Encrypted Integrity Protected Data packet,
       including prefix data, the tag octet, and length octet of the
       Modification Detection Code packet.

   Note that the Modification Detection Code packet MUST always use a
   new format encoding of the packet tag, and a one-octet encoding of
   the packet length.  The reason for this is that the hashing rules for
   modification detection include a one-octet tag and one-octet length
   in the data hash.  While this is a bit restrictive, it reduces
   complexity.

6.  Radix-64 Conversions

   As stated in the introduction, OpenPGP's underlying native
   representation for objects is a stream of arbitrary octets, and some
   systems desire these objects to be immune to damage caused by
   character set translation, data conversions, etc.

   In principle, any printable encoding scheme that met the requirements
   of the unsafe channel would suffice, since it would not change the
   underlying binary bit streams of the native OpenPGP data structures.
   The OpenPGP standard specifies one such printable encoding scheme to
   ensure interoperability.

   OpenPGP's Radix-64 encoding is composed of two parts: a base64
   encoding of the binary data and a checksum.  The base64 encoding is
   identical to the MIME base64 content-transfer-encoding [RFC2045].

   The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to
   four characters of radix-64 encoding by the same MIME base64
   transformation, preceded by an equal sign (=).  The CRC is computed
   by using the generator 0x864CFB and an initialization of 0xB704CE.
   The accumulation is done on the data before it is converted to
   radix-64, rather than on the converted data.  A sample implementation
   of this algorithm is in the next section.

   The checksum with its leading equal sign MAY appear on the first line
   after the base64 encoded data.

   Rationale for CRC-24: The size of 24 bits fits evenly into printable
   base64.  The nonzero initialization can detect more errors than a
   zero initialization.



Callas, et al               Standards Track                    [Page 53]

RFC 4880                 OpenPGP Message Format            November 2007


6.1.  An Implementation of the CRC-24 in "C"

      #define CRC24_INIT 0xB704CEL
      #define CRC24_POLY 0x1864CFBL

      typedef long crc24;
      crc24 crc_octets(unsigned char *octets, size_t len)
      {
          crc24 crc = CRC24_INIT;
          int i;
          while (len--) {
              crc ^= (*octets++) << 16;
              for (i = 0; i < 8; i++) {
                  crc <<= 1;
                  if (crc & 0x1000000)
                      crc ^= CRC24_POLY;
              }
          }
          return crc & 0xFFFFFFL;
      }

6.2.  Forming ASCII Armor

   When OpenPGP encodes data into ASCII Armor, it puts specific headers
   around the Radix-64 encoded data, so OpenPGP can reconstruct the data
   later.  An OpenPGP implementation MAY use ASCII armor to protect raw
   binary data.  OpenPGP informs the user what kind of data is encoded
   in the ASCII armor through the use of the headers.

   Concatenating the following data creates ASCII Armor:

     - An Armor Header Line, appropriate for the type of data

     - Armor Headers

     - A blank (zero-length, or containing only whitespace) line

     - The ASCII-Armored data

     - An Armor Checksum

     - The Armor Tail, which depends on the Armor Header Line

   An Armor Header Line consists of the appropriate header line text
   surrounded by five (5) dashes ('-', 0x2D) on either side of the
   header line text.  The header line text is chosen based upon the type
   of data that is being encoded in Armor, and how it is being encoded.
   Header line texts include the following strings:



Callas, et al               Standards Track                    [Page 54]

RFC 4880                 OpenPGP Message Format            November 2007


   BEGIN PGP MESSAGE
       Used for signed, encrypted, or compressed files.

   BEGIN PGP PUBLIC KEY BLOCK
       Used for armoring public keys.

   BEGIN PGP PRIVATE KEY BLOCK
       Used for armoring private keys.

   BEGIN PGP MESSAGE, PART X/Y
       Used for multi-part messages, where the armor is split amongst Y
       parts, and this is the Xth part out of Y.

   BEGIN PGP MESSAGE, PART X
       Used for multi-part messages, where this is the Xth part of an
       unspecified number of parts.  Requires the MESSAGE-ID Armor
       Header to be used.

   BEGIN PGP SIGNATURE
       Used for detached signatures, OpenPGP/MIME signatures, and
       cleartext signatures.  Note that PGP 2.x uses BEGIN PGP MESSAGE
       for detached signatures.

   Note that all these Armor Header Lines are to consist of a complete
   line.  That is to say, there is always a line ending preceding the
   starting five dashes, and following the ending five dashes.  The
   header lines, therefore, MUST start at the beginning of a line, and
   MUST NOT have text other than whitespace following them on the same
   line.  These line endings are considered a part of the Armor Header
   Line for the purposes of determining the content they delimit.  This
   is particularly important when computing a cleartext signature (see
   below).

   The Armor Headers are pairs of strings that can give the user or the
   receiving OpenPGP implementation some information about how to decode
   or use the message.  The Armor Headers are a part of the armor, not a
   part of the message, and hence are not protected by any signatures
   applied to the message.

   The format of an Armor Header is that of a key-value pair.  A colon
   (':' 0x38) and a single space (0x20) separate the key and value.
   OpenPGP should consider improperly formatted Armor Headers to be
   corruption of the ASCII Armor.  Unknown keys should be reported to
   the user, but OpenPGP should continue to process the message.

   Note that some transport methods are sensitive to line length.  While
   there is a limit of 76 characters for the Radix-64 data (Section
   6.3), there is no limit to the length of Armor Headers.  Care should



Callas, et al               Standards Track                    [Page 55]

RFC 4880                 OpenPGP Message Format            November 2007


   be taken that the Armor Headers are short enough to survive
   transport.  One way to do this is to repeat an Armor Header key
   multiple times with different values for each so that no one line is
   overly long.

   Currently defined Armor Header Keys are as follows:

     - "Version", which states the OpenPGP implementation and version
       used to encode the message.

     - "Comment", a user-defined comment.  OpenPGP defines all text to
       be in UTF-8.  A comment may be any UTF-8 string.  However, the
       whole point of armoring is to provide seven-bit-clean data.
       Consequently, if a comment has characters that are outside the
       US-ASCII range of UTF, they may very well not survive transport.

     - "MessageID", a 32-character string of printable characters.  The
       string must be the same for all parts of a multi-part message
       that uses the "PART X" Armor Header.  MessageID strings should be
       unique enough that the recipient of the mail can associate all
       the parts of a message with each other.  A good checksum or
       cryptographic hash function is sufficient.

       The MessageID SHOULD NOT appear unless it is in a multi-part
       message.  If it appears at all, it MUST be computed from the
       finished (encrypted, signed, etc.) message in a deterministic
       fashion, rather than contain a purely random value.  This is to
       allow the legitimate recipient to determine that the MessageID
       cannot serve as a covert means of leaking cryptographic key
       information.

     - "Hash", a comma-separated list of hash algorithms used in this
       message.  This is used only in cleartext signed messages.

     - "Charset", a description of the character set that the plaintext
       is in.  Please note that OpenPGP defines text to be in UTF-8.  An
       implementation will get best results by translating into and out
       of UTF-8.  However, there are many instances where this is easier
       said than done.  Also, there are communities of users who have no
       need for UTF-8 because they are all happy with a character set
       like ISO Latin-5 or a Japanese character set.  In such instances,
       an implementation MAY override the UTF-8 default by using this
       header key.  An implementation MAY implement this key and any
       translations it cares to; an implementation MAY ignore it and
       assume all text is UTF-8.






Callas, et al               Standards Track                    [Page 56]

RFC 4880                 OpenPGP Message Format            November 2007


       The Armor Tail Line is composed in the same manner as the Armor
       Header Line, except the string "BEGIN" is replaced by the string
       "END".

6.3.  Encoding Binary in Radix-64

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters.  Proceeding from left to right, a
   24-bit input group is formed by concatenating three 8-bit input
   groups.  These 24 bits are then treated as four concatenated 6-bit
   groups, each of which is translated into a single digit in the
   Radix-64 alphabet.  When encoding a bit stream with the Radix-64
   encoding, the bit stream must be presumed to be ordered with the most
   significant bit first.  That is, the first bit in the stream will be
   the high-order bit in the first 8-bit octet, and the eighth bit will
   be the low-order bit in the first 8-bit octet, and so on.

         +--first octet--+-second octet--+--third octet--+
         |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
         +-----------+---+-------+-------+---+-----------+
         |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
         +--1.index--+--2.index--+--3.index--+--4.index--+

   Each 6-bit group is used as an index into an array of 64 printable
   characters from the table below.  The character referenced by the
   index is placed in the output string.

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w         (pad) =
        15 P            32 g            49 x
        16 Q            33 h            50 y

   The encoded output stream must be represented in lines of no more
   than 76 characters each.



Callas, et al               Standards Track                    [Page 57]

RFC 4880                 OpenPGP Message Format            November 2007


   Special processing is performed if fewer than 24 bits are available
   at the end of the data being encoded.  There are three possibilities:

   1. The last data group has 24 bits (3 octets).  No special processing
      is needed.

   2. The last data group has 16 bits (2 octets).  The first two 6-bit
      groups are processed as above.  The third (incomplete) data group
      has two zero-value bits added to it, and is processed as above.  A
      pad character (=) is added to the output.

   3. The last data group has 8 bits (1 octet).  The first 6-bit group
      is processed as above.  The second (incomplete) data group has
      four zero-value bits added to it, and is processed as above.  Two
      pad characters (=) are added to the output.

6.4.  Decoding Radix-64

   In Radix-64 data, characters other than those in the table, line
   breaks, and other white space probably indicate a transmission error,
   about which a warning message or even a message rejection might be
   appropriate under some circumstances.  Decoding software must ignore
   all white space.

   Because it is used only for padding at the end of the data, the
   occurrence of any "=" characters may be taken as evidence that the
   end of the data has been reached (without truncation in transit).  No
   such assurance is possible, however, when the number of octets
   transmitted was a multiple of three and no "=" characters are
   present.


Callas, et al               Standards Track                    [Page 58]

RFC 4880                 OpenPGP Message Format            November 2007


6.5.  Examples of Radix-64

   Input data:  0x14FB9C03D97E
   Hex:     1   4    F   B    9   C     | 0   3    D   9    7   E
   8-bit:   00010100 11111011 10011100  | 00000011 11011001 11111110
   6-bit:   000101 001111 101110 011100 | 000000 111101 100111 111110
   Decimal: 5      15     46     28       0      61     37     62
   Output:  F      P      u      c        A      9      l      +
   Input data:  0x14FB9C03D9
   Hex:     1   4    F   B    9   C     | 0   3    D   9
   8-bit:   00010100 11111011 10011100  | 00000011 11011001
                                                   pad with 00
   6-bit:   000101 001111 101110 011100 | 000000 111101 100100
   Decimal: 5      15     46     28       0      61     36
                                                      pad with =
   Output:  F      P      u      c        A      9      k      =
   Input data:  0x14FB9C03
   Hex:     1   4    F   B    9   C     | 0   3
   8-bit:   00010100 11111011 10011100  | 00000011
                                          pad with 0000
   6-bit:   000101 001111 101110 011100 | 000000 110000
   Decimal: 5      15     46     28       0      48
                                               pad with =      =
   Output:  F      P      u      c        A      w      =      =

6.6.  Example of an ASCII Armored Message

   -----BEGIN PGP MESSAGE-----
   Version: OpenPrivacy 0.99

   yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
   vBSFjNSiVHsuAA==
   =njUN
   -----END PGP MESSAGE-----

   Note that this example has extra indenting; an actual armored message
   would have no leading whitespace.

7.  Cleartext Signature Framework

   It is desirable to be able to sign a textual octet stream without
   ASCII armoring the stream itself, so the signed text is still
   readable without special software.  In order to bind a signature to
   such a cleartext, this framework is used.  (Note that this framework
   is not intended to be reversible.  RFC 3156 [RFC3156] defines another
   way to sign cleartext messages for environments that support MIME.)




Callas, et al               Standards Track                    [Page 59]

RFC 4880                 OpenPGP Message Format            November 2007


   The cleartext signed message consists of:

     - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
       single line,

     - One or more "Hash" Armor Headers,

     - Exactly one empty line not included into the message digest,

     - The dash-escaped cleartext that is included into the message
       digest,

     - The ASCII armored signature(s) including the '-----BEGIN PGP
       SIGNATURE-----' Armor Header and Armor Tail Lines.

   If the "Hash" Armor Header is given, the specified message digest
   algorithm(s) are used for the signature.  If there are no such
   headers, MD5 is used.  If MD5 is the only hash used, then an
   implementation MAY omit this header for improved V2.x compatibility.
   If more than one message digest is used in the signature, the "Hash"
   armor header contains a comma-delimited list of used message digests.

   Current message digest names are described below with the algorithm
   IDs.

   An implementation SHOULD add a line break after the cleartext, but
   MAY omit it if the cleartext ends with a line break.  This is for
   visual clarity.

7.1.  Dash-Escaped Text

   The cleartext content of the message must also be dash-escaped.

   Dash-escaped cleartext is the ordinary cleartext where every line
   starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
   (0x2D) and space ' ' (0x20).  This prevents the parser from
   recognizing armor headers of the cleartext itself.  An implementation
   MAY dash-escape any line, SHOULD dash-escape lines commencing "From"
   followed by a space, and MUST dash-escape any line commencing in a
   dash.  The message digest is computed using the cleartext itself, not
   the dash-escaped form.

   As with binary signatures on text documents, a cleartext signature is
   calculated on the text using canonical <CR><LF> line endings.  The
   line ending (i.e., the <CR><LF>) before the '-----BEGIN PGP
   SIGNATURE-----' line that terminates the signed text is not
   considered part of the signed text.




Callas, et al               Standards Track                    [Page 60]

RFC 4880                 OpenPGP Message Format            November 2007


   When reversing dash-escaping, an implementation MUST strip the string
   "- " if it occurs at the beginning of a line, and SHOULD warn on "-"
   and any character other than a space at the beginning of a line.

   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
   the end of any line is removed when the cleartext signature is
   generated.

8.  Regular Expressions

   A regular expression is zero or more branches, separated by '|'.  It
   matches anything that matches one of the branches.

   A branch is zero or more pieces, concatenated.  It matches a match
   for the first, followed by a match for the second, etc.

   A piece is an atom possibly followed by '*', '+', or '?'.  An atom
   followed by '*' matches a sequence of 0 or more matches of the atom.
   An atom followed by '+' matches a sequence of 1 or more matches of
   the atom.  An atom followed by '?' matches a match of the atom, or
   the null string.

   An atom is a regular expression in parentheses (matching a match for
   the regular expression), a range (see below), '.' (matching any
   single character), '^' (matching the null string at the beginning of
   the input string), '$' (matching the null string at the end of the
   input string), a '\' followed by a single character (matching that
   character), or a single character with no other significance
   (matching that character).

   A range is a sequence of characters enclosed in '[]'.  It normally
   matches any single character from the sequence.  If the sequence
   begins with '^', it matches any single character not from the rest of
   the sequence.  If two characters in the sequence are separated
   by '-', this is shorthand for the full list of ASCII characters
   between them (e.g., '[0-9]' matches any decimal digit).  To include a
   literal ']' in the sequence, make it the first character (following a
   possible '^').  To include a literal '-', make it the first or last
   character.

9.  Constants

   This section describes the constants used in OpenPGP.

   Note that these tables are not exhaustive lists; an implementation
   MAY implement an algorithm not on these lists, so long as the
   algorithm numbers are chosen from the private or experimental
   algorithm range.



Callas, et al               Standards Track                    [Page 61]

RFC 4880                 OpenPGP Message Format            November 2007


   See the section "Notes on Algorithms" below for more discussion of
   the algorithms.

9.1.  Public-Key Algorithms

      ID           Algorithm
      --           ---------
      1          - RSA (Encrypt or Sign) [HAC]
      2          - RSA Encrypt-Only [HAC]
      3          - RSA Sign-Only [HAC]
      16         - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
      17         - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
      18         - Reserved for Elliptic Curve
      19         - Reserved for ECDSA
      20         - Reserved (formerly Elgamal Encrypt or Sign)
      21         - Reserved for Diffie-Hellman (X9.42,
                   as defined for IETF-S/MIME)
      100 to 110 - Private/Experimental algorithm

   Implementations MUST implement DSA for signatures, and Elgamal for
   encryption.  Implementations SHOULD implement RSA keys (1).  RSA
   Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
   generated, but may be interpreted.  See Section 13.5.  See Section
   13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or
   Sign (20), and X9.42 (21).  Implementations MAY implement any other
   algorithm.

9.2.  Symmetric-Key Algorithms

       ID           Algorithm
       --           ---------
       0          - Plaintext or unencrypted data
       1          - IDEA [IDEA]
       2          - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
                    168 bit key derived from 192)
       3          - CAST5 (128 bit key, as per [RFC2144])
       4          - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
       5          - Reserved
       6          - Reserved
       7          - AES with 128-bit key [AES]
       8          - AES with 192-bit key
       9          - AES with 256-bit key
       10         - Twofish with 256-bit key [TWOFISH]
       100 to 110 - Private/Experimental algorithm

   Implementations MUST implement TripleDES.  Implementations SHOULD
   implement AES-128 and CAST5.  Implementations that interoperate with




Callas, et al               Standards Track                    [Page 62]

RFC 4880                 OpenPGP Message Format            November 2007


   PGP 2.6 or earlier need to support IDEA, as that is the only
   symmetric cipher those versions use.  Implementations MAY implement
   any other algorithm.

9.3.  Compression Algorithms

       ID           Algorithm
       --           ---------
       0          - Uncompressed
       1          - ZIP [RFC1951]
       2          - ZLIB [RFC1950]
       3          - BZip2 [BZ2]
       100 to 110 - Private/Experimental algorithm

   Implementations MUST implement uncompressed data.  Implementations
   SHOULD implement ZIP.  Implementations MAY implement any other
   algorithm.

9.4.  Hash Algorithms

      ID           Algorithm                             Text Name
      --           ---------                             ---------
      1          - MD5 [HAC]                             "MD5"
      2          - SHA-1 [FIPS180]                       "SHA1"
      3          - RIPE-MD/160 [HAC]                     "RIPEMD160"
      4          - Reserved
      5          - Reserved
      6          - Reserved
      7          - Reserved
      8          - SHA256 [FIPS180]                      "SHA256"
      9          - SHA384 [FIPS180]                      "SHA384"
      10         - SHA512 [FIPS180]                      "SHA512"
      11         - SHA224 [FIPS180]                      "SHA224"
      100 to 110 - Private/Experimental algorithm

   Implementations MUST implement SHA-1.  Implementations MAY implement
   other algorithms.  MD5 is deprecated.

10.  IANA Considerations

   OpenPGP is highly parameterized, and consequently there are a number
   of considerations for allocating parameters for extensions.  This
   section describes how IANA should look at extensions to the protocol
   as described in this document.



Callas, et al               Standards Track                    [Page 63]

RFC 4880                 OpenPGP Message Format            November 2007


10.1.  New String-to-Key Specifier Types

   OpenPGP S2K specifiers contain a mechanism for new algorithms to turn
   a string into a key.  This specification creates a registry of S2K
   specifier types.  The registry includes the S2K type, the name of the
   S2K, and a reference to the defining specification.  The initial
   values for this registry can be found in Section 3.7.1.  Adding a new
   S2K specifier MUST be done through the IETF CONSENSUS method, as
   described in [RFC2434].

10.2.  New Packets

   Major new features of OpenPGP are defined through new packet types.
   This specification creates a registry of packet types.  The registry
   includes the packet type, the name of the packet, and a reference to
   the defining specification.  The initial values for this registry can
   be found in Section 4.3.  Adding a new packet type MUST be done
   through the IETF CONSENSUS method, as described in [RFC2434].

10.2.1.  User Attribute Types

   The User Attribute packet permits an extensible mechanism for other
   types of certificate identification.  This specification creates a
   registry of User Attribute types.  The registry includes the User
   Attribute type, the name of the User Attribute, and a reference to
   the defining specification.  The initial values for this registry can
   be found in Section 5.12.  Adding a new User Attribute type MUST be
   done through the IETF CONSENSUS method, as described in [RFC2434].

10.2.1.1.  Image Format Subpacket Types

   Within User Attribute packets, there is an extensible mechanism for
   other types of image-based user attributes.  This specification
   creates a registry of Image Attribute subpacket types.  The registry
   includes the Image Attribute subpacket type, the name of the Image
   Attribute subpacket, and a reference to the defining specification.
   The initial values for this registry can be found in Section 5.12.1.
   Adding a new Image Attribute subpacket type MUST be done through the
   IETF CONSENSUS method, as described in [RFC2434].

10.2.2.  New Signature Subpackets

   OpenPGP signatures contain a mechanism for signed (or unsigned) data
   to be added to them for a variety of purposes in the Signature
   subpackets as discussed in Section 5.2.3.1.  This specification
   creates a registry of Signature subpacket types.  The registry
   includes the Signature subpacket type, the name of the subpacket, and
   a reference to the defining specification.  The initial values for



Callas, et al               Standards Track                    [Page 64]

RFC 4880                 OpenPGP Message Format            November 2007


   this registry can be found in Section 5.2.3.1.  Adding a new
   Signature subpacket MUST be done through the IETF CONSENSUS method,
   as described in [RFC2434].

10.2.2.1.  Signature Notation Data Subpackets

   OpenPGP signatures further contain a mechanism for extensions in
   signatures.  These are the Notation Data subpackets, which contain a
   key/value pair.  Notations contain a user space that is completely
   unmanaged and an IETF space.

   This specification creates a registry of Signature Notation Data
   types.  The registry includes the Signature Notation Data type, the
   name of the Signature Notation Data, its allowed values, and a
   reference to the defining specification.  The initial values for this
   registry can be found in Section 5.2.3.16.  Adding a new Signature
   Notation Data subpacket MUST be done through the EXPERT REVIEW
   method, as described in [RFC2434].

10.2.2.2.  Key Server Preference Extensions

   OpenPGP signatures contain a mechanism for preferences to be
   specified about key servers.  This specification creates a registry
   of key server preferences.  The registry includes the key server
   preference, the name of the preference, and a reference to the
   defining specification.  The initial values for this registry can be
   found in Section 5.2.3.17.  Adding a new key server preference MUST
   be done through the IETF CONSENSUS method, as described in [RFC2434].

10.2.2.3.  Key Flags Extensions

   OpenPGP signatures contain a mechanism for flags to be specified
   about key usage.  This specification creates a registry of key usage
   flags.  The registry includes the key flags value, the name of the
   flag, and a reference to the defining specification.  The initial
   values for this registry can be found in Section 5.2.3.21.  Adding a
   new key usage flag MUST be done through the IETF CONSENSUS method, as
   described in [RFC2434].

10.2.2.4.  Reason for Revocation Extensions

   OpenPGP signatures contain a mechanism for flags to be specified
   about why a key was revoked.  This specification creates a registry
   of "Reason for Revocation" flags.  The registry includes the "Reason
   for Revocation" flags value, the name of the flag, and a reference to
   the defining specification.  The initial values for this registry can
   be found in Section 5.2.3.23.  Adding a new feature flag MUST be done
   through the IETF CONSENSUS method, as described in [RFC2434].



Callas, et al               Standards Track                    [Page 65]

RFC 4880                 OpenPGP Message Format            November 2007


10.2.2.5.  Implementation Features

   OpenPGP signatures contain a mechanism for flags to be specified
   stating which optional features an implementation supports.  This
   specification creates a registry of feature-implementation flags.
   The registry includes the feature-implementation flags value, the
   name of the flag, and a reference to the defining specification.  The
   initial values for this registry can be found in Section 5.2.3.24.
   Adding a new feature-implementation flag MUST be done through the
   IETF CONSENSUS method, as described in [RFC2434].

   Also see Section 13.12 for more information about when feature flags
   are needed.

10.2.3.  New Packet Versions

   The core OpenPGP packets all have version numbers, and can be revised
   by introducing a new version of an existing packet.  This
   specification creates a registry of packet types.  The registry
   includes the packet type, the number of the version, and a reference
   to the defining specification.  The initial values for this registry
   can be found in Section 5.  Adding a new packet version MUST be done
   through the IETF CONSENSUS method, as described in [RFC2434].

10.3.  New Algorithms

   Section 9 lists the core algorithms that OpenPGP uses.  Adding in a
   new algorithm is usually simple.  For example, adding in a new
   symmetric cipher usually would not need anything more than allocating
   a constant for that cipher.  If that cipher had other than a 64-bit
   or 128-bit block size, there might need to be additional
   documentation describing how OpenPGP-CFB mode would be adjusted.
   Similarly, when DSA was expanded from a maximum of 1024-bit public
   keys to 3072-bit public keys, the revision of FIPS 186 contained
   enough information itself to allow implementation.  Changes to this
   document were made mainly for emphasis.

10.3.1.  Public-Key Algorithms

   OpenPGP specifies a number of public-key algorithms.  This
   specification creates a registry of public-key algorithm identifiers.
   The registry includes the algorithm name, its key sizes and
   parameters, and a reference to the defining specification.  The
   initial values for this registry can be found in Section 9.  Adding a
   new public-key algorithm MUST be done through the IETF CONSENSUS
   method, as described in [RFC2434].





Callas, et al               Standards Track                    [Page 66]

RFC 4880                 OpenPGP Message Format            November 2007


10.3.2.  Symmetric-Key Algorithms

   OpenPGP specifies a number of symmetric-key algorithms.  This
   specification creates a registry of symmetric-key algorithm
   identifiers.  The registry includes the algorithm name, its key sizes
   and block size, and a reference to the defining specification.  The
   initial values for this registry can be found in Section 9.  Adding a
   new symmetric-key algorithm MUST be done through the IETF CONSENSUS
   method, as described in [RFC2434].

10.3.3.  Hash Algorithms

   OpenPGP specifies a number of hash algorithms.  This specification
   creates a registry of hash algorithm identifiers.  The registry
   includes the algorithm name, a text representation of that name, its
   block size, an OID hash prefix, and a reference to the defining
   specification.  The initial values for this registry can be found in
   Section 9 for the algorithm identifiers and text names, and Section
   5.2.2 for the OIDs and expanded signature prefixes.  Adding a new
   hash algorithm MUST be done through the IETF CONSENSUS method, as
   described in [RFC2434].

10.3.4.  Compression Algorithms

   OpenPGP specifies a number of compression algorithms.  This
   specification creates a registry of compression algorithm
   identifiers.  The registry includes the algorithm name and a
   reference to the defining specification.  The initial values for this
   registry can be found in Section 9.3.  Adding a new compression key
   algorithm MUST be done through the IETF CONSENSUS method, as
   described in [RFC2434].

11.  Packet Composition

   OpenPGP packets are assembled into sequences in order to create
   messages and to transfer keys.  Not all possible packet sequences are
   meaningful and correct.  This section describes the rules for how
   packets should be placed into sequences.

11.1.  Transferable Public Keys

   OpenPGP users may transfer public keys.  The essential elements of a
   transferable public key are as follows:

     - One Public-Key packet

     - Zero or more revocation signatures


Callas, et al               Standards Track                    [Page 67]

RFC 4880                 OpenPGP Message Format            November 2007


     - One or more User ID packets

     - After each User ID packet, zero or more Signature packets
       (certifications)

     - Zero or more User Attribute packets

     - After each User Attribute packet, zero or more Signature packets
       (certifications)

     - Zero or more Subkey packets

     - After each Subkey packet, one Signature packet, plus optionally a
       revocation

   The Public-Key packet occurs first.  Each of the following User ID
   packets provides the identity of the owner of this public key.  If
   there are multiple User ID packets, this corresponds to multiple
   means of identifying the same unique individual user; for example, a
   user may have more than one email address, and construct a User ID
   for each one.

   Immediately following each User ID packet, there are zero or more
   Signature packets.  Each Signature packet is calculated on the
   immediately preceding User ID packet and the initial Public-Key
   packet.  The signature serves to certify the corresponding public key
   and User ID.  In effect, the signer is testifying to his or her
   belief that this public key belongs to the user identified by this
   User ID.

   Within the same section as the User ID packets, there are zero or
   more User Attribute packets.  Like the User ID packets, a User
   Attribute packet is followed by zero or more Signature packets
   calculated on the immediately preceding User Attribute packet and the
   initial Public-Key packet.

   User Attribute packets and User ID packets may be freely intermixed
   in this section, so long as the signatures that follow them are
   maintained on the proper User Attribute or User ID packet.

   After the User ID packet or Attribute packet, there may be zero or
   more Subkey packets.  In general, subkeys are provided in cases where
   the top-level public key is a signature-only key.  However, any V4
   key may have subkeys, and the subkeys may be encryption-only keys,
   signature-only keys, or general-purpose keys.  V3 keys MUST NOT have
   subkeys.


Callas, et al               Standards Track                    [Page 68]

RFC 4880                 OpenPGP Message Format            November 2007


   Each Subkey packet MUST be followed by one Signature packet, which
   should be a subkey binding signature issued by the top-level key.
   For subkeys that can issue signatures, the subkey binding signature
   MUST contain an Embedded Signature subpacket with a primary key
   binding signature (0x19) issued by the subkey on the top-level key.

   Subkey and Key packets may each be followed by a revocation Signature
   packet to indicate that the key is revoked.  Revocation signatures
   are only accepted if they are issued by the key itself, or by a key
   that is authorized to issue revocations via a Revocation Key
   subpacket in a self-signature by the top-level key.

   Transferable public-key packet sequences may be concatenated to allow
   transferring multiple public keys in one operation.

11.2.  Transferable Secret Keys

   OpenPGP users may transfer secret keys.  The format of a transferable
   secret key is the same as a transferable public key except that
   secret-key and secret-subkey packets are used instead of the public
   key and public-subkey packets.  Implementations SHOULD include self-
   signatures on any user IDs and subkeys, as this allows for a complete
   public key to be automatically extracted from the transferable secret
   key.  Implementations MAY choose to omit the self-signatures,
   especially if a transferable public key accompanies the transferable
   secret key.

11.3.  OpenPGP Messages

   An OpenPGP message is a packet or sequence of packets that
   corresponds to the following grammatical rules (comma represents
   sequential composition, and vertical bar separates alternatives):

   OpenPGP Message :- Encrypted Message | Signed Message |
                      Compressed Message | Literal Message.

   Compressed Message :- Compressed Data Packet.

   Literal Message :- Literal Data Packet.

   ESK :- Public-Key Encrypted Session Key Packet |
          Symmetric-Key Encrypted Session Key Packet.

   ESK Sequence :- ESK | ESK Sequence, ESK.

   Encrypted Data :- Symmetrically Encrypted Data Packet |
         Symmetrically Encrypted Integrity Protected Data Packet




Callas, et al               Standards Track                    [Page 69]

RFC 4880                 OpenPGP Message Format            November 2007


   Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data.

   One-Pass Signed Message :- One-Pass Signature Packet,
               OpenPGP Message, Corresponding Signature Packet.

   Signed Message :- Signature Packet, OpenPGP Message |
               One-Pass Signed Message.

   In addition, decrypting a Symmetrically Encrypted Data packet or a
   Symmetrically Encrypted Integrity Protected Data packet as well as
   decompressing a Compressed Data packet must yield a valid OpenPGP
   Message.

11.4.  Detached Signatures

   Some OpenPGP applications use so-called "detached signatures".  For
   example, a program bundle may contain a file, and with it a second
   file that is a detached signature of the first file.  These detached
   signatures are simply a Signature packet stored separately from the
   data for which they are a signature.

12.  Enhanced Key Formats

12.1.  Key Structures

   The format of an OpenPGP V3 key is as follows.  Entries in square
   brackets are optional and ellipses indicate repetition.

           RSA Public Key
              [Revocation Self Signature]
               User ID [Signature ...]
              [User ID [Signature ...] ...]

   Each signature certifies the RSA public key and the preceding User
   ID.  The RSA public key can have many User IDs and each User ID can
   have many signatures.  V3 keys are deprecated.  Implementations MUST
   NOT generate new V3 keys, but MAY continue to use existing ones.

   The format of an OpenPGP V4 key that uses multiple public keys is
   similar except that the other keys are added to the end as "subkeys"
   of the primary key.


Callas, et al               Standards Track                    [Page 70]

RFC 4880                 OpenPGP Message Format            November 2007


           Primary-Key
              [Revocation Self Signature]
              [Direct Key Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [User Attribute [Signature ...] ...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

   A subkey always has a single signature after it that is issued using
   the primary key to tie the two keys together.  This binding signature
   may be in either V3 or V4 format, but SHOULD be V4.  Subkeys that can
   issue signatures MUST have a V4 binding signature due to the REQUIRED
   embedded primary key binding signature.

   In the above diagram, if the binding signature of a subkey has been
   revoked, the revoked key may be removed, leaving only one key.

   In a V4 key, the primary key MUST be a key capable of certification.
   The subkeys may be keys of any other type.  There may be other
   constructions of V4 keys, too.  For example, there may be a single-
   key RSA key in V4 format, a DSA primary key with an RSA encryption
   key, or RSA primary key with an Elgamal subkey, etc.

   It is also possible to have a signature-only subkey.  This permits a
   primary key that collects certifications (key signatures), but is
   used only for certifying subkeys that are used for encryption and
   signatures.

12.2.  Key IDs and Fingerprints

   For a V3 key, the eight-octet Key ID consists of the low 64 bits of
   the public modulus of the RSA key.

   The fingerprint of a V3 key is formed by hashing the body (but not
   the two-octet length) of the MPIs that form the key material (public
   modulus n, followed by exponent e) with MD5.  Note that both V3 keys
   and MD5 are deprecated.

   A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
   followed by the two-octet packet length, followed by the entire
   Public-Key packet starting with the version field.  The Key ID is the
   low-order 64 bits of the fingerprint.  Here are the fields of the
   hash material, with the example of a DSA key:

   a.1) 0x99 (1 octet)

   a.2) high-order length octet of (b)-(e) (1 octet)



Callas, et al               Standards Track                    [Page 71]

RFC 4880                 OpenPGP Message Format            November 2007


   a.3) low-order length octet of (b)-(e) (1 octet)

     b) version number = 4 (1 octet);

     c) timestamp of key creation (4 octets);

     d) algorithm (1 octet): 17 = DSA (example);

     e) Algorithm-specific fields.

   Algorithm-Specific Fields for DSA keys (example):

   e.1) MPI of DSA prime p;

   e.2) MPI of DSA group order q (q is a prime divisor of p-1);

   e.3) MPI of DSA group generator g;

   e.4) MPI of DSA public-key value y (= g**x mod p where x is secret).

   Note that it is possible for there to be collisions of Key IDs -- two
   different keys with the same Key ID.  Note that there is a much
   smaller, but still non-zero, probability that two different keys have
   the same fingerprint.

   Also note that if V3 and V4 format keys share the same RSA key
   material, they will have different Key IDs as well as different
   fingerprints.

   Finally, the Key ID and fingerprint of a subkey are calculated in the
   same way as for a primary key, including the 0x99 as the first octet
   (even though this is not a valid packet ID for a public subkey).

13.  Notes on Algorithms

13.1.  PKCS#1 Encoding in OpenPGP

   This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and
   EMSA-PKCS1-v1_5.  However, the calling conventions of these functions
   has changed in the past.  To avoid potential confusion and
   interoperability problems, we are including local copies in this
   document, adapted from those in PKCS#1 v2.1 [RFC3447].  RFC 3447
   should be treated as the ultimate authority on PKCS#1 for OpenPGP.
   Nonetheless, we believe that there is value in having a self-
   contained document that avoids problems in the future with needed
   changes in the conventions.





Callas, et al               Standards Track                    [Page 72]

RFC 4880                 OpenPGP Message Format            November 2007


13.1.1.  EME-PKCS1-v1_5-ENCODE

   Input:

   k  = the length in octets of the key modulus

   M  = message to be encoded, an octet string of length mLen, where
        mLen <= k - 11

   Output:

   EM = encoded message, an octet string of length k

   Error:   "message too long"

     1. Length checking: If mLen > k - 11, output "message too long" and
        stop.

     2. Generate an octet string PS of length k - mLen - 3 consisting of
        pseudo-randomly generated nonzero octets.  The length of PS will
        be at least eight octets.

     3. Concatenate PS, the message M, and other padding to form an
        encoded message EM of length k octets as

        EM = 0x00 || 0x02 || PS || 0x00 || M.

     4. Output EM.

13.1.2.  EME-PKCS1-v1_5-DECODE

   Input:

   EM = encoded message, an octet string

   Output:

   M  = message, an octet string

   Error:   "decryption error"

   To decode an EME-PKCS1_v1_5 message, separate the encoded message EM
   into an octet string PS consisting of nonzero octets and a message M
   as follows

     EM = 0x00 || 0x02 || PS || 0x00 || M.



Callas, et al               Standards Track                    [Page 73]

RFC 4880                 OpenPGP Message Format            November 2007


   If the first octet of EM does not have hexadecimal value 0x00, if the
   second octet of EM does not have hexadecimal value 0x02, if there is
   no octet with hexadecimal value 0x00 to separate PS from M, or if the
   length of PS is less than 8 octets, output "decryption error" and
   stop.  See also the security note in Section 14 regarding differences
   in reporting between a decryption error and a padding error.

13.1.3.  EMSA-PKCS1-v1_5

   This encoding method is deterministic and only has an encoding
   operation.

   Option:

   Hash - a hash function in which hLen denotes the length in octets of
         the hash function output

   Input:

   M  = message to be encoded

   mL = intended length in octets of the encoded message, at least tLen
        + 11, where tLen is the octet length of the DER encoding T of a
        certain value computed during the encoding operation

   Output:

   EM = encoded message, an octet string of length emLen

   Errors: "message too long"; "intended encoded message length too
   short"

   Steps:

     1. Apply the hash function to the message M to produce a hash value
        H:

        H = Hash(M).

        If the hash function outputs "message too long," output "message
        too long" and stop.

     2. Using the list in Section 5.2.2, produce an ASN.1 DER value for
        the hash function used.  Let T be the full hash prefix from
        Section 5.2.2, and let tLen be the length in octets of T.

     3. If emLen < tLen + 11, output "intended encoded message length
        too short" and stop.



Callas, et al               Standards Track                    [Page 74]

RFC 4880                 OpenPGP Message Format            November 2007


     4. Generate an octet string PS consisting of emLen - tLen - 3
        octets with hexadecimal value 0xFF.  The length of PS will be at
        least 8 octets.

     5. Concatenate PS, the hash prefix T, and other padding to form the
        encoded message EM as

        EM = 0x00 || 0x01 || PS || 0x00 || T.

     6. Output EM.

13.2.  Symmetric Algorithm Preferences

   The symmetric algorithm preference is an ordered list of algorithms
   that the keyholder accepts.  Since it is found on a self-signature,
   it is possible that a keyholder may have multiple, different
   preferences.  For example, Alice may have TripleDES only specified
   for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for
   "alice@home.org".  Note that it is also possible for preferences to
   be in a subkey's binding signature.

   Since TripleDES is the MUST-implement algorithm, if it is not
   explicitly in the list, it is tacitly at the end.  However, it is
   good form to place it there explicitly.  Note also that if an
   implementation does not implement the preference, then it is
   implicitly a TripleDES-only implementation.

   An implementation MUST NOT use a symmetric algorithm that is not in
   the recipient's preference list.  When encrypting to more than one
   recipient, the implementation finds a suitable algorithm by taking
   the intersection of the preferences of the recipients.  Note that the
   MUST-implement algorithm, TripleDES, ensures that the intersection is
   not null.  The implementation may use any mechanism to pick an
   algorithm in the intersection.

   If an implementation can decrypt a message that a keyholder doesn't
   have in their preferences, the implementation SHOULD decrypt the
   message anyway, but MUST warn the keyholder that the protocol has
   been violated.  For example, suppose that Alice, above, has software
   that implements all algorithms in this specification.  Nonetheless,
   she prefers subsets for work or home.  If she is sent a message
   encrypted with IDEA, which is not in her preferences, the software
   warns her that someone sent her an IDEA-encrypted message, but it
   would ideally decrypt it anyway.



Callas, et al               Standards Track                    [Page 75]

RFC 4880                 OpenPGP Message Format            November 2007


13.3.  Other Algorithm Preferences

   Other algorithm preferences work similarly to the symmetric algorithm
   preference, in that they specify which algorithms the keyholder
   accepts.  There are two interesting cases that other comments need to
   be made about, though, the compression preferences and the hash
   preferences.

13.3.1.  Compression Preferences

   Compression has been an integral part of PGP since its first days.
   OpenPGP and all previous versions of PGP have offered compression.
   In this specification, the default is for messages to be compressed,
   although an implementation is not required to do so.  Consequently,
   the compression preference gives a way for a keyholder to request
   that messages not be compressed, presumably because they are using a
   minimal implementation that does not include compression.
   Additionally, this gives a keyholder a way to state that it can
   support alternate algorithms.

   Like the algorithm preferences, an implementation MUST NOT use an
   algorithm that is not in the preference vector.  If the preferences
   are not present, then they are assumed to be [ZIP(1),
   Uncompressed(0)].

   Additionally, an implementation MUST implement this preference to the
   degree of recognizing when to send an uncompressed message.  A robust
   implementation would satisfy this requirement by looking at the
   recipient's preference and acting accordingly.  A minimal
   implementation can satisfy this requirement by never generating a
   compressed message, since all implementations can handle messages
   that have not been compressed.

13.3.2.  Hash Algorithm Preferences

   Typically, the choice of a hash algorithm is something the signer
   does, rather than the verifier, because a signer rarely knows who is
   going to be verifying the signature.  This preference, though, allows
   a protocol based upon digital signatures ease in negotiation.

   Thus, if Alice is authenticating herself to Bob with a signature, it
   makes sense for her to use a hash algorithm that Bob's software uses.
   This preference allows Bob to state in his key which algorithms Alice
   may use.

   Since SHA1 is the MUST-implement hash algorithm, if it is not
   explicitly in the list, it is tacitly at the end.  However, it is
   good form to place it there explicitly.



Callas, et al               Standards Track                    [Page 76]

RFC 4880                 OpenPGP Message Format            November 2007


13.4.  Plaintext

   Algorithm 0, "plaintext", may only be used to denote secret keys that
   are stored in the clear.  Implementations MUST NOT use plaintext in
   Symmetrically Encrypted Data packets; they must use Literal Data
   packets to encode unencrypted or literal data.

13.5.  RSA

   There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
   keys.  These types are deprecated.  The "key flags" subpacket in a
   signature is a much better way to express the same idea, and
   generalizes it to all algorithms.  An implementation SHOULD NOT
   create such a key, but MAY interpret it.

   An implementation SHOULD NOT implement RSA keys of size less than
   1024 bits.

13.6.  DSA

   An implementation SHOULD NOT implement DSA keys of size less than
   1024 bits.  It MUST NOT implement a DSA key with a q size of less
   than 160 bits.  DSA keys MUST also be a multiple of 64 bits, and the
   q size MUST be a multiple of 8 bits.  The Digital Signature Standard
   (DSS) [FIPS186] specifies that DSA be used in one of the following
   ways:

     * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or
       SHA-512 hash

     * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
       hash

     * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

     * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

   The above key and q size pairs were chosen to best balance the
   strength of the key with the strength of the hash.  Implementations
   SHOULD use one of the above key and q size pairs when generating DSA
   keys.  If DSS compliance is desired, one of the specified SHA hashes
   must be used as well.  [FIPS186] is the ultimate authority on DSS,
   and should be consulted for all questions of DSS compliance.

   Note that earlier versions of this standard only allowed a 160-bit q
   with no truncation allowed, so earlier implementations may not be
   able to handle signatures with a different q size or a truncated
   hash.



Callas, et al               Standards Track                    [Page 77]

RFC 4880                 OpenPGP Message Format            November 2007


13.7.  Elgamal

   An implementation SHOULD NOT implement Elgamal keys of size less than
   1024 bits.

13.8.  Reserved Algorithm Numbers

   A number of algorithm IDs have been reserved for algorithms that
   would be useful to use in an OpenPGP implementation, yet there are
   issues that prevent an implementer from actually implementing the
   algorithm.  These are marked in Section 9.1, "Public-Key Algorithms",
   as "reserved for".

   The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19),
   and X9.42 (21), do not have the necessary parameters, parameter
   order, or semantics defined.

   Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
   with a public-key identifier of 20.  These are no longer permitted.
   An implementation MUST NOT generate such keys.  An implementation
   MUST NOT generate Elgamal signatures.  See [BLEICHENBACHER].

13.9.  OpenPGP CFB Mode

   OpenPGP does symmetric encryption using a variant of Cipher Feedback
   mode (CFB mode).  This section describes the procedure it uses in
   detail.  This mode is what is used for Symmetrically Encrypted Data
   Packets; the mechanism used for encrypting secret-key material is
   similar, and is described in the sections above.

   In the description below, the value BS is the block size in octets of
   the cipher.  Most ciphers have a block size of 8 octets.  The AES and
   Twofish have a block size of 16 octets.  Also note that the
   description below assumes that the IV and CFB arrays start with an
   index of 1 (unlike the C language, which assumes arrays start with a
   zero index).

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
   prefixes the plaintext with BS+2 octets of random data, such that
   octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
   resynchronization after encrypting those BS+2 octets.

   Thus, for an algorithm that has a block size of 8 octets (64 bits),
   the IV is 10 octets long and octets 7 and 8 of the IV are the same as
   octets 9 and 10.  For an algorithm with a block size of 16 octets
   (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
   octets 15 and 16.  Those extra two octets are an easy check for a
   correct key.



Callas, et al               Standards Track                    [Page 78]

RFC 4880                 OpenPGP Message Format            November 2007


   Step by step, here is the procedure:

   1.  The feedback register (FR) is set to the IV, which is all zeros.

   2.  FR is encrypted to produce FRE (FR Encrypted).  This is the
       encryption of an all-zero value.

   3.  FRE is xored with the first BS octets of random data prefixed to
       the plaintext to produce C[1] through C[BS], the first BS octets
       of ciphertext.

   4.  FR is loaded with C[1] through C[BS].

   5.  FR is encrypted to produce FRE, the encryption of the first BS
       octets of ciphertext.

   6.  The left two octets of FRE get xored with the next two octets of
       data that were prefixed to the plaintext.  This produces C[BS+1]
       and C[BS+2], the next two octets of ciphertext.

   7.  (The resynchronization step) FR is loaded with C[3] through
       C[BS+2].

   8.  FR is encrypted to produce FRE.

   9.  FRE is xored with the first BS octets of the given plaintext, now
       that we have finished encrypting the BS+2 octets of prefixed
       data.  This produces C[BS+3] through C[BS+(BS+2)], the next BS
       octets of ciphertext.

   10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for
       an 8-octet block).

       11. FR is encrypted to produce FRE.

       12. FRE is xored with the next BS octets of plaintext, to produce
       the next BS octets of ciphertext.  These are loaded into FR, and
       the process is repeated until the plaintext is used up.

13.10.  Private or Experimental Parameters

   S2K specifiers, Signature subpacket types, user attribute types,
   image format types, and algorithms described in Section 9 all reserve
   the range 100 to 110 for private and experimental use.  Packet types
   reserve the range 60 to 63 for private and experimental use.  These
   are intentionally managed with the PRIVATE USE method, as described
   in [RFC2434].




Callas, et al               Standards Track                    [Page 79]

RFC 4880                 OpenPGP Message Format            November 2007


   However, implementations need to be careful with these and promote
   them to full IANA-managed parameters when they grow beyond the
   original, limited system.

13.11.  Extension of the MDC System

   As described in the non-normative explanation in Section 5.13, the
   MDC system is uniquely unparameterized in OpenPGP.  This was an
   intentional decision to avoid cross-grade attacks.  If the MDC system
   is extended to a stronger hash function, care must be taken to avoid
   downgrade and cross-grade attacks.

   One simple way to do this is to create new packets for a new MDC.
   For example, instead of the MDC system using packets 18 and 19, a new
   MDC could use 20 and 21.  This has obvious drawbacks (it uses two
   packet numbers for each new hash function in a space that is limited
   to a maximum of 60).

   Another simple way to extend the MDC system is to create new versions
   of packet 18, and reflect this in packet 19.  For example, suppose
   that V2 of packet 18 implicitly used SHA-256.  This would require
   packet 19 to have a length of 32 octets.  The change in the version
   in packet 18 and the size of packet 19 prevent a downgrade attack.

   There are two drawbacks to this latter approach.  The first is that
   using the version number of a packet to carry algorithm information
   is not tidy from a protocol-design standpoint.  It is possible that
   there might be several versions of the MDC system in common use, but
   this untidiness would reflect untidiness in cryptographic consensus
   about hash function security.  The second is that different versions
   of packet 19 would have to have unique sizes.  If there were two
   versions each with 256-bit hashes, they could not both have 32-octet
   packet 19s without admitting the chance of a cross-grade attack.

   Yet another, complex approach to extend the MDC system would be a
   hybrid of the two above -- create a new pair of MDC packets that are
   fully parameterized, and yet protected from downgrade and cross-
   grade.

   Any change to the MDC system MUST be done through the IETF CONSENSUS
   method, as described in [RFC2434].

13.12.  Meta-Considerations for Expansion

   If OpenPGP is extended in a way that is not backwards-compatible,
   meaning that old implementations will not gracefully handle their





Callas, et al               Standards Track                    [Page 80]

RFC 4880                 OpenPGP Message Format            November 2007


   absence of a new feature, the extension proposal can be declared in
   the key holder's self-signature as part of the Features signature
   subpacket.

   We cannot state definitively what extensions will not be upwards-
   compatible, but typically new algorithms are upwards-compatible,
   whereas new packets are not.

   If an extension proposal does not update the Features system, it
   SHOULD include an explanation of why this is unnecessary.  If the
   proposal contains neither an extension to the Features system nor an
   explanation of why such an extension is unnecessary, the proposal
   SHOULD be rejected.

14.  Security Considerations

   * As with any technology involving cryptography, you should check the
     current literature to determine if any algorithms used here have
     been found to be vulnerable to attack.

   * This specification uses Public-Key Cryptography technologies.  It
     is assumed that the private key portion of a public-private key
     pair is controlled and secured by the proper party or parties.

   * Certain operations in this specification involve the use of random
     numbers.  An appropriate entropy source should be used to generate
     these numbers (see [RFC4086]).

   * The MD5 hash algorithm has been found to have weaknesses, with
     collisions found in a number of cases.  MD5 is deprecated for use
     in OpenPGP.  Implementations MUST NOT generate new signatures using
     MD5 as a hash function.  They MAY continue to consider old
     signatures that used MD5 as valid.

   * SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512,
     respectively.  In general, there are few reasons to use them
     outside of DSS compatibility.  You need a situation where one needs
     more security than smaller hashes, but does not want to have the
     full 256-bit or 512-bit data length.

   * Many security protocol designers think that it is a bad idea to use
     a single key for both privacy (encryption) and integrity
     (signatures).  In fact, this was one of the motivating forces
     behind the V4 key format with separate signature and encryption
     keys.  If you as an implementer promote dual-use keys, you should
     at least be aware of this controversy.





Callas, et al               Standards Track                    [Page 81]

RFC 4880                 OpenPGP Message Format            November 2007


   * The DSA algorithm will work with any hash, but is sensitive to the
     quality of the hash algorithm.  Verifiers should be aware that even
     if the signer used a strong hash, an attacker could have modified
     the signature to use a weak one.  Only signatures using acceptably
     strong hash algorithms should be accepted as valid.

   * As OpenPGP combines many different asymmetric, symmetric, and hash
     algorithms, each with different measures of strength, care should
     be taken that the weakest element of an OpenPGP message is still
     sufficiently strong for the purpose at hand.  While consensus about
     the strength of a given algorithm may evolve, NIST Special
     Publication 800-57 [SP800-57] recommends the following list of
     equivalent strengths:

           Asymmetric  |  Hash  |  Symmetric
            key size   |  size  |   key size
           ------------+--------+-----------
              1024        160         80
              2048        224        112
              3072        256        128
              7680        384        192
             15360        512        256

   * There is a somewhat-related potential security problem in
     signatures.  If an attacker can find a message that hashes to the
     same hash with a different algorithm, a bogus signature structure
     can be constructed that evaluates correctly.

     For example, suppose Alice DSA signs message M using hash algorithm
     H.  Suppose that Mallet finds a message M' that has the same hash
     value as M with H'.  Mallet can then construct a signature block
     that verifies as Alice's signature of M' with H'.  However, this
     would also constitute a weakness in either H or H' or both.  Should
     this ever occur, a revision will have to be made to this document
     to revise the allowed hash algorithms.

   * If you are building an authentication system, the recipient may
     specify a preferred signing algorithm.  However, the signer would
     be foolish to use a weak algorithm simply because the recipient
     requests it.

   * Some of the encryption algorithms mentioned in this document have
     been analyzed less than others.  For example, although CAST5 is
     presently considered strong, it has been analyzed less than
     TripleDES.  Other algorithms may have other controversies
     surrounding them.





Callas, et al               Standards Track                    [Page 82]

RFC 4880                 OpenPGP Message Format            November 2007


   * In late summer 2002, Jallad, Katz, and Schneier published an
     interesting attack on the OpenPGP protocol and some of its
     implementations [JKS02].  In this attack, the attacker modifies a
     message and sends it to a user who then returns the erroneously
     decrypted message to the attacker.  The attacker is thus using the
     user as a random oracle, and can often decrypt the message.

     Compressing data can ameliorate this attack.  The incorrectly
     decrypted data nearly always decompresses in ways that defeat the
     attack.  However, this is not a rigorous fix, and leaves open some
     small vulnerabilities.  For example, if an implementation does not
     compress a message before encryption (perhaps because it knows it
     was already compressed), then that message is vulnerable.  Because
     of this happenstance -- that modification attacks can be thwarted
     by decompression errors -- an implementation SHOULD treat a
     decompression error as a security problem, not merely a data
     problem.

     This attack can be defeated by the use of Modification Detection,
     provided that the implementation does not let the user naively
     return the data to the attacker.  An implementation MUST treat an
     MDC failure as a security problem, not merely a data problem.

     In either case, the implementation MAY allow the user access to the
     erroneous data, but MUST warn the user as to potential security
     problems should that data be returned to the sender.

     While this attack is somewhat obscure, requiring a special set of
     circumstances to create it, it is nonetheless quite serious as it
     permits someone to trick a user to decrypt a message.
     Consequently, it is important that:

      1. Implementers treat MDC errors and decompression failures as
         security problems.

      2. Implementers implement Modification Detection with all due
         speed and encourage its spread.

      3. Users migrate to implementations that support Modification
         Detection with all due speed.

   * PKCS#1 has been found to be vulnerable to attacks in which a system
     that reports errors in padding differently from errors in
     decryption becomes a random oracle that can leak the private key in
     mere millions of queries.  Implementations must be aware of this
     attack and prevent it from happening.  The simplest solution is to
     report a single error code for all variants of decryption errors so
     as not to leak information to an attacker.



Callas, et al               Standards Track                    [Page 83]

RFC 4880                 OpenPGP Message Format            November 2007


   * Some technologies mentioned here may be subject to government
     control in some countries.

   * In winter 2005, Serge Mister and Robert Zuccherato from Entrust
     released a paper describing a way that the "quick check" in OpenPGP
     CFB mode can be used with a random oracle to decrypt two octets of
     every cipher block [MZ05].  They recommend as prevention not using
     the quick check at all.

     Many implementers have taken this advice to heart for any data that
     is symmetrically encrypted and for which the session key is
     public-key encrypted.  In this case, the quick check is not needed
     as the public-key encryption of the session key should guarantee
     that it is the right session key.  In other cases, the
     implementation should use the quick check with care.

     On the one hand, there is a danger to using it if there is a random
     oracle that can leak information to an attacker.  In plainer
     language, there is a danger to using the quick check if timing
     information about the check can be exposed to an attacker,
     particularly via an automated service that allows rapidly repeated
     queries.

     On the other hand, it is inconvenient to the user to be informed
     that they typed in the wrong passphrase only after a petabyte of
     data is decrypted.  There are many cases in cryptographic
     engineering where the implementer must use care and wisdom, and
     this is one.

15.  Implementation Nits

   This section is a collection of comments to help an implementer,
   particularly with an eye to backward compatibility.  Previous
   implementations of PGP are not OpenPGP compliant.  Often the
   differences are small, but small differences are frequently more
   vexing than large differences.  Thus, this is a non-comprehensive
   list of potential problems and gotchas for a developer who is trying
   to be backward-compatible.

     * The IDEA algorithm is patented, and yet it is required for PGP
       2.x interoperability.  It is also the de-facto preferred
       algorithm for a V3 key with a V3 self-signature (or no self-
       signature).

     * When exporting a private key, PGP 2.x generates the header "BEGIN
       PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK".
       All previous versions ignore the implied data type, and look
       directly at the packet data type.



Callas, et al               Standards Track                    [Page 84]

RFC 4880                 OpenPGP Message Format            November 2007


     * PGP 2.0 through 2.5 generated V2 Public-Key packets.  These are
       identical to the deprecated V3 keys except for the version
       number.  An implementation MUST NOT generate them and may accept
       or reject them as it sees fit.  Some older PGP versions generated
       V2 PKESK packets (Tag 1) as well.  An implementation may accept
       or reject V2 PKESK packets as it sees fit, and MUST NOT generate
       them.

     * PGP 2.6.x will not accept key-material packets with versions
       greater than 3.

     * There are many ways possible for two keys to have the same key
       material, but different fingerprints (and thus Key IDs).  Perhaps
       the most interesting is an RSA key that has been "upgraded" to V4
       format, but since a V4 fingerprint is constructed by hashing the
       key creation time along with other things, two V4 keys created at
       different times, yet with the same key material will have
       different fingerprints.

     * If an implementation is using zlib to interoperate with PGP 2.x,
       then the "windowBits" parameter should be set to -13.

     * The 0x19 back signatures were not required for signing subkeys
       until relatively recently.  Consequently, there may be keys in
       the wild that do not have these back signatures.  Implementing
       software may handle these keys as it sees fit.

     * OpenPGP does not put limits on the size of public keys.  However,
       larger keys are not necessarily better keys.  Larger keys take
       more computation time to use, and this can quickly become
       impractical.  Different OpenPGP implementations may also use
       different upper bounds for public key sizes, and so care should
       be taken when choosing sizes to maintain interoperability.  As of
       2007 most implementations have an upper bound of 4096 bits.

     * ASCII armor is an optional feature of OpenPGP.  The OpenPGP
       working group strives for a minimal set of mandatory-to-implement
       features, and since there could be useful implementations that
       only use binary object formats, this is not a "MUST" feature for
       an implementation.  For example, an implementation that is using
       OpenPGP as a mechanism for file signatures may find ASCII armor
       unnecessary. OpenPGP permits an implementation to declare what
       features it does and does not support, but ASCII armor is not one
       of these.  Since most implementations allow binary and armored
       objects to be used indiscriminately, an implementation that does
       not implement ASCII armor may find itself with compatibility
       issues with general-purpose implementations.  Moreover,
       implementations of OpenPGP-MIME [RFC3156] already have a



Callas, et al               Standards Track                    [Page 85]

RFC 4880                 OpenPGP Message Format            November 2007


       requirement for ASCII armor so those implementations will
       necessarily have support.

16.  References

16.1.  Normative References

   [AES]            NIST, FIPS PUB 197, "Advanced Encryption Standard
                    (AES)," November 2001.
                    http://csrc.nist.gov/publications/fips/fips197/fips-
                    197.{ps,pdf}

   [BLOWFISH]       Schneier, B. "Description of a New Variable-Length
                    Key, 64-Bit Block Cipher (Blowfish)" Fast Software
                    Encryption, Cambridge Security Workshop Proceedings
                    (December 1993), Springer-Verlag, 1994, pp191-204
                    <http://www.counterpane.com/bfsverlag.html>

   [BZ2]            J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
                    home page" <http://www.bzip.org/>

   [ELGAMAL]        T. Elgamal, "A Public-Key Cryptosystem and a
                    Signature Scheme Based on Discrete Logarithms," IEEE
                    Transactions on Information Theory, v. IT-31, n. 4,
                    1985, pp. 469-472.

   [FIPS180]        Secure Hash Signature Standard (SHS) (FIPS PUB 180-
                    2).
                    <http://csrc.nist.gov/publications/fips/fips180-
                    2/fips180-2withchangenotice.pdf>

   [FIPS186]        Digital Signature Standard (DSS) (FIPS PUB 186-2).
                    <http://csrc.nist.gov/publications/fips/fips186-2/
                     fips186-2-change1.pdf> FIPS 186-3 describes keys
                    greater than 1024 bits.  The latest draft is at:
                    <http://csrc.nist.gov/publications/drafts/
                    fips_186-3/Draft-FIPS-186-3%20_March2006.pdf>

   [HAC]            Alfred Menezes, Paul van Oorschot, and Scott
                    Vanstone, "Handbook of Applied Cryptography," CRC
                    Press, 1996.
                    <http://www.cacr.math.uwaterloo.ca/hac/>

   [IDEA]           Lai, X, "On the design and security of block
                    ciphers", ETH Series in Information Processing, J.L.
                    Massey (editor), Vol. 1, Hartung-Gorre Verlag
                    Knostanz, Technische Hochschule (Zurich), 1992



Callas, et al               Standards Track                    [Page 86]

RFC 4880                 OpenPGP Message Format            November 2007


   [ISO10646]       ISO/IEC 10646-1:1993. International Standard --
                    Information technology -- Universal Multiple-Octet
                    Coded Character Set (UCS) -- Part 1: Architecture
                    and Basic Multilingual Plane.

   [JFIF]           JPEG File Interchange Format (Version 1.02).  Eric
                    Hamilton, C-Cube Microsystems, Milpitas, CA,
                    September 1, 1992.

   [RFC1950]        Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                    Format Specification version 3.3", RFC 1950, May
                    1996.

   [RFC1951]        Deutsch, P., "DEFLATE Compressed Data Format
                    Specification version 1.3", RFC 1951, May 1996.

   [RFC2045]        Freed, N. and N. Borenstein, "Multipurpose Internet
                    Mail Extensions (MIME) Part One: Format of Internet
                    Message Bodies", RFC 2045, November 1996

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2144]        Adams, C., "The CAST-128 Encryption Algorithm", RFC
                    2144, May 1997.

   [RFC2434]        Narten, T. and H. Alvestrand, "Guidelines for
                    Writing an IANA Considerations Section in RFCs", BCP
                    26, RFC 2434, October 1998.

   [RFC2822]        Resnick, P., "Internet Message Format", RFC 2822,
                    April 2001.

   [RFC3156]        Elkins, M., Del Torto, D., Levien, R., and T.
                    Roessler, "MIME Security with OpenPGP", RFC 3156,
                    August 2001.

   [RFC3447]        Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                    Standards (PKCS) #1: RSA Cryptography Specifications
                    Version 2.1", RFC 3447, February 2003.

   [RFC3629]        Yergeau, F., "UTF-8, a transformation format of ISO
                    10646", STD 63, RFC 3629, November 2003.

   [RFC4086]        Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                    "Randomness Requirements for Security", BCP 106, RFC
                    4086, June 2005.




Callas, et al               Standards Track                    [Page 87]

RFC 4880                 OpenPGP Message Format            November 2007


   [SCHNEIER]      Schneier, B., "Applied Cryptography Second Edition:
                    protocols, algorithms, and source code in C", 1996.

   [TWOFISH]        B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
                    Hall, and N. Ferguson, "The Twofish Encryption
                    Algorithm", John Wiley & Sons, 1999.

16.2.  Informative References

   [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
                    signatures without knowing the secret key,"
                    Eurocrypt 96. Note that the version in the
                    proceedings has an error. A revised version is
                    available at the time of writing from
                    <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
                    /isc/ElGamal.ps>

   [JKS02]          Kahil Jallad, Jonathan Katz, Bruce Schneier
                    "Implementation of Chosen-Ciphertext Attacks against
                    PGP and GnuPG" http://www.counterpane.com/pgp-
                    attack.html

   [MAURER]         Ueli Maurer, "Modelling a Public-Key
                    Infrastructure", Proc. 1996 European Symposium on
                    Research in Computer Security (ESORICS' 96), Lecture
                    Notes in Computer Science, Springer-Verlag, vol.
                    1146, pp. 325-350, Sep 1996.

   [MZ05]           Serge Mister, Robert Zuccherato, "An Attack on CFB
                    Mode Encryption As Used By OpenPGP," IACR ePrint
                    Archive: Report 2005/033, 8 Feb 2005
                    http://eprint.iacr.org/2005/033

   [REGEX]          Jeffrey Friedl, "Mastering Regular Expressions,"
                    O'Reilly, ISBN 0-596-00289-0.

   [RFC1423]        Balenson, D., "Privacy Enhancement for Internet
                    Electronic Mail: Part III: Algorithms, Modes, and
                    Identifiers", RFC 1423, February 1993.

   [RFC1991]        Atkins, D., Stallings, W., and P. Zimmermann, "PGP
                    Message Exchange Formats", RFC 1991, August 1996.

   [RFC2440]        Callas, J., Donnerhacke, L., Finney, H., and R.
                    Thayer, "OpenPGP Message Format", RFC 2440, November
                    1998.



Callas, et al               Standards Track                    [Page 88]

RFC 4880                 OpenPGP Message Format            November 2007


   [SP800-57]       NIST Special Publication 800-57, Recommendation on
                    Key Management
                    <http://csrc.nist.gov/publications/nistpubs/ 800-
                    57/SP800-57-Part1.pdf>
                    <http://csrc.nist.gov/publications/nistpubs/ 800-
                    57/SP800-57-Part2.pdf>

Acknowledgements

   This memo also draws on much previous work from a number of other
   authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc
   Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie,
   Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings,
   Mark Weaver, and Philip R. Zimmermann.

Authors' Addresses

   The working group can be contacted via the current chair:

      Derek Atkins
      IHTFP Consulting, Inc.
      4 Farragut Ave
      Somerville, MA  02144  USA

      EMail: derek@ihtfp.com
      Tel: +1 617 623 3745

   The principal authors of this document are as follows:

      Jon Callas
      EMail: jon@callas.org

      Lutz Donnerhacke
      IKS GmbH
      Wildenbruchstr. 15
      07745 Jena, Germany
      EMail: lutz@iks-jena.de

      Hal Finney
      EMail: hal@finney.org

      David Shaw
      EMail: dshaw@jabberwocky.com

      Rodney Thayer
      EMail: rodney@canola-jones.com



Callas, et al               Standards Track                    [Page 89]

RFC 4880                 OpenPGP Message Format            November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












Callas, et al               Standards Track                    [Page 90]

RFC 8077

Research, RFC, Technology
Internet Engineering Task Force (IETF)                   L. Martini, Ed.
Request for Comments: 8077                                 G. Heron, Ed.
STD: 84                                                            Cisco
Obsoletes: 4447, 6723                                      February 2017
Category: Standards Track
ISSN: 2070-1721


                    Pseudowire Setup and Maintenance
              Using the Label Distribution Protocol (LDP)

Abstract

   Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode,
   and Ethernet) can be emulated over an MPLS backbone by encapsulating
   the Layer 2 Protocol Data Units (PDUs) and then transmitting them
   over pseudowires (PWs).  It is also possible to use pseudowires to
   provide low-rate Time-Division Multiplexed and Synchronous Optical
   NETworking circuit emulation over an MPLS-enabled network.  This
   document specifies a protocol for establishing and maintaining the
   pseudowires, using extensions to the Label Distribution Protocol
   (LDP).  Procedures for encapsulating Layer 2 PDUs are specified in
   other documents.

   This document is a rewrite of RFC 4447 for publication as an Internet
   Standard.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8077.

Martini & Heron              Standards Track                    [Page 1]

RFC 8077                     PWE3 Using LDP                February 2017


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Martini & Heron              Standards Track                    [Page 2]

RFC 8077                     PWE3 Using LDP                February 2017


Table of Contents

   1. Introduction ....................................................4
   2. Changes from RFC 4447 ...........................................6
   3. Specification of Requirements ...................................6
   4. The Pseudowire Label ............................................7
   5. Details Specific to Particular Emulated Services ................9
      5.1. IP Layer 2 Transport .......................................9
   6. LDP .............................................................9
      6.1. The PWid FEC Element .......................................9
      6.2. The Generalized PWid FEC Element ..........................11
           6.2.1. Attachment Identifiers .............................12
           6.2.2. Encoding the Generalized PWid FEC Element ..........14
                  6.2.2.1. PW Interface Parameters TLV ...............15
                  6.2.2.2. PW Group ID TLV ...........................15
           6.2.3. Signaling Procedures ...............................16
      6.3. Signaling of Pseudowire Status ............................17
           6.3.1. Use of Label Mapping Messages ......................17
           6.3.2. Signaling PW Status ................................18
           6.3.3. Pseudowire Status Negotiation Procedures ...........19
      6.4. Interface Parameter Sub-TLV ...............................20
      6.5. LDP Label Withdrawal Procedures ...........................21
   7. Control Word ...................................................22
      7.1. PW Types for Which the Control Word Is REQUIRED ...........22
      7.2. PW Types for Which the Control Word Is NOT Mandatory ......22
      7.3. Control-Word Renegotiation by Label Request Message .......24
      7.4. Sequencing Considerations .................................25
           7.4.1. Label Advertisements ...............................25
           7.4.2. Label Release ......................................25
   8. IANA Considerations ............................................26
      8.1. LDP TLV TYPE ..............................................26
      8.2. LDP Status Codes ..........................................26
      8.3. FEC Type Name Space .......................................26
   9. Security Considerations ........................................26
      9.1. Data-Plane Security .......................................27
      9.2. Control-Plane Security ....................................28
   10. Interoperability and Deployment ...............................29
   11. References ....................................................29
      11.1. Normative References .....................................29
      11.2. Informative References ...................................30
   Acknowledgments ...................................................31
   Contributors ......................................................32
   Authors' Addresses ................................................35



Martini & Heron              Standards Track                    [Page 3]

RFC 8077                     PWE3 Using LDP                February 2017


1.  Introduction

   [RFC4619], [RFC4717], [RFC4618], and [RFC4448] explain how to
   encapsulate a Layer 2 Protocol Data Unit (PDU) for transmission over
   an MPLS-enabled network.  Those documents specify that a "pseudowire
   header", consisting of a demultiplexer field, will be prepended to
   the encapsulated PDU.  The pseudowire demultiplexer field is
   prepended before transmitting a packet on a pseudowire.  When the
   packet arrives at the remote endpoint of the pseudowire, the
   demultiplexer is what enables the receiver to identify the particular
   pseudowire on which the packet has arrived.  To transmit the packet
   from one pseudowire endpoint to another, the packet may need to
   travel through a "Packet Switched Network (PSN) tunnel"; this will
   require that an additional header be prepended to the packet.

   [RFC4842] and [RFC4553] specify two methods for transporting time-
   division multiplexing (TDM) digital signals (TDM circuit emulation)
   over a packet-oriented MPLS-enabled network.  The transmission system
   for circuit-oriented TDM signals is the Synchronous Optical Network
   (SONET) [ANSI] / Synchronous Digital Hierarchy (SDH) [ITUG].  To
   support TDM traffic, which includes voice, data, and private leased-
   line service, the pseudowires must emulate the circuit
   characteristics of SONET/SDH payloads.  The TDM signals and payloads
   are encapsulated for transmission over pseudowires.  A pseudowire
   demultiplexer and a PSN tunnel header are prepended to this
   encapsulation.

   [RFC4553] describes methods for transporting low-rate time-division
   multiplexing (TDM) digital signals (TDM circuit emulation) over PSNs,
   while [RFC4842] similarly describes transport of high-rate TDM
   (SONET/SDH).  To support TDM traffic, the pseudowires must emulate
   the circuit characteristics of the original T1, E1, T3, E3, SONET, or
   SDH signals.  [RFC4553] does this by encapsulating an arbitrary but
   constant amount of the TDM data in each packet, and the other methods
   encapsulate TDM structures.

   In this document, we specify the use of the MPLS Label Distribution
   Protocol (LDP) [RFC5036] as a protocol for setting up and maintaining
   the pseudowires.  In particular, we define new TLVs, Forwarding
   Equivalence Class (FEC) elements, parameters, and codes for LDP,
   which enable LDP to identify pseudowires and to signal attributes of
   pseudowires.  We specify how a pseudowire endpoint uses these TLVs in
   LDP to bind a demultiplexer field value to a pseudowire and how it
   informs the remote endpoint of the binding.  We also specify
   procedures for reporting pseudowire status changes, for passing
   additional information about the pseudowire as needed, and for
   releasing the bindings.  These procedures are intended to be
   independent of the underlying version of IP used for LDP signaling.



Martini & Heron              Standards Track                    [Page 4]

RFC 8077                     PWE3 Using LDP                February 2017


   In the protocol specified herein, the pseudowire demultiplexer field
   is an MPLS label.  Thus, the packets that are transmitted from one
   end of the pseudowire to the other are MPLS packets, which must be
   transmitted through an MPLS tunnel.  However, if the pseudowire
   endpoints are immediately adjacent and penultimate hop popping
   behavior is in use, the MPLS tunnel may not be necessary.  Any sort
   of PSN tunnel can be used, as long as it is possible to transmit MPLS
   packets through it.  The PSN tunnel can itself be an MPLS LSP, or any
   other sort of tunnel that can carry MPLS packets.  Procedures for
   setting up and maintaining the MPLS tunnels are outside the scope of
   this document.

   This document deals only with the setup and maintenance of point-to-
   point pseudowires.  Neither point-to-multipoint nor multipoint-to-
   point pseudowires are discussed.

   QoS-related issues are not discussed in this document.

   The following two figures describe the reference models that are
   derived from [RFC3985] to support the PW emulated services.

         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<------- Pseudowire ------->|          |
         |          |                            |          |
         |Attachment|    |<-- PSN Tunnel -->|    |Attachment|
         |  Circuit V    V                  V    V  Circuit |
         V   (AC)   +----+                  +----+   (AC)   V
   +-----+    |     | PE1|==================| PE2|     |    +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^ |     |    |==================|    |     | ^  +-----+
         ^  |       +----+                  +----+     | |  ^
         |  |   Provider Edge 1         Provider Edge 2  |  |
         |  |                                            |  |
   Customer |                                            | Customer
   Edge 1   |                                            | Edge 2
            |                                            |
      native service                               native service

                     Figure 1: PWE3 Reference Model



Martini & Heron              Standards Track                    [Page 5]

RFC 8077                     PWE3 Using LDP                February 2017


    +-----------------+                           +-----------------+
    |Emulated Service |                           |Emulated Service |
    |(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
    +-----------------+                           +-----------------+
    |    Payload      |                           |    Payload      |
    |  Encapsulation  |<====== Pseudowire =======>|  Encapsulation  |
    +-----------------+                           +-----------------+
    |PW Demultiplexer |                           |PW Demultiplexer |
    |   PSN Tunnel,   |<======= PSN Tunnel ======>|  PSN Tunnel,    |
    | PSN & Physical  |                           | PSN & Physical  |
    |     Layers      |                           |    Layers       |
    +-------+---------+        ___________        +---------+-------+
            |                /             \                 |
            +===============/     PSN       \================+
                            \               /
                             \_____________/

              Figure 2: PWE3 Protocol Stack Reference Model

   For the purpose of this document, PE1 (Provider Edge 1) will be
   defined as the ingress router, and PE2 as the egress router.  A Layer
   2 PDU will be received at PE1, encapsulated at PE1, transported and
   decapsulated at PE2, and transmitted out of PE2.

2.  Changes from RFC 4447

   The changes in this document are mostly minor fixes to spelling and
   grammar, or clarifications to the text, which were either noted as
   errata to [RFC4447] or found by the editors.

   Additionally, Section 7.3 ("Control-Word Renegotiation by Label
   Request Message") has been added, obsoleting [RFC6723].  The diagram
   of C-bit handling procedures has also been removed.  A note has been
   added in Section 6.3.2 to clarify that the C-bit is part of the FEC.

   A reference has also been added to [RFC7358] to indicate the use of
   downstream unsolicited mode to distribute PW FEC label bindings,
   independent of the negotiated label advertisement mode of the LDP
   session.

3.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Martini & Heron              Standards Track                    [Page 6]

RFC 8077                     PWE3 Using LDP                February 2017


4.  The Pseudowire Label

   Suppose that it is desired to transport Layer 2 PDUs from ingress LSR
   PE1 to egress LSR PE2, across an intervening MPLS-enabled network.
   We assume that there is an MPLS tunnel from PE1 to PE2.  That is, we
   assume that PE1 can cause a packet to be delivered to PE2 by
   encapsulating the packet in an "MPLS tunnel header" and sending the
   result to one of its adjacencies.  The MPLS tunnel is an MPLS Label
   Switched Path (LSP); thus, putting on an MPLS tunnel encapsulation is
   a matter of pushing on an MPLS label.

   We presuppose that a large number of pseudowires can be carried
   through a single MPLS tunnel.  Thus, it is never necessary to
   maintain state in the network core for individual pseudowires.  We do
   not presuppose that the MPLS tunnels are point to point; although the
   pseudowires are point to point, the MPLS tunnels may be multipoint to
   point.  We do not presuppose that PE2 will even be able to determine
   the MPLS tunnel through which a received packet was transmitted.
   (For example, if the MPLS tunnel is an LSP and penultimate hop
   popping is used, when the packet arrives at PE2, it will contain no
   information identifying the tunnel.)

   When PE2 receives a packet over a pseudowire, it must be able to
   determine that the packet was in fact received over a pseudowire, and
   it must be able to associate that packet with a particular
   pseudowire.  PE2 is able to do this by examining the MPLS label that
   serves as the pseudowire demultiplexer field shown in Figure 2.  Call
   this label the "PW label".

   When PE1 sends a Layer 2 PDU to PE2, it creates an MPLS packet by
   adding the PW label to the packet, thus creating the first entry of
   the label stack.  If the PSN tunnel is an MPLS LSP, the PE1 pushes
   another label (the tunnel label) onto the packet as the second entry
   of the label stack.  The PW label is not visible again until the MPLS
   packet reaches PE2.  PE2's disposition of the packet is based on the
   PW label.

   If the payload of the MPLS packet is, for example, an ATM Adaptation
   Layer 5 (AAL5) PDU, the PW label will generally correspond to a
   particular ATM Virtual Circuit (VC) at PE2.  That is, PE2 needs to be
   able to infer from the PW label the outgoing interface and the
   VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier) value
   for the AAL5 PDU.  If the payload is a Frame Relay PDU, then PE2
   needs to be able to infer from the PW label the outgoing interface
   and the Data Link Connection Identifier (DLCI) value.  If the payload
   is an Ethernet frame, then PE2 needs to be able to infer from the PW
   label the outgoing interface, and perhaps the VLAN identifier.  This
   process is unidirectional and will be repeated independently for



Martini & Heron              Standards Track                    [Page 7]

RFC 8077                     PWE3 Using LDP                February 2017


   bidirectional operation.  When using the PWid FEC Element, it is
   REQUIRED that the same PW ID and PW type be assigned for a given
   circuit in both directions.  The Group ID (see below) MUST NOT be
   required to match in both directions.  The transported frame MAY be
   modified when it reaches the egress router.  If the header of the
   transported Layer 2 frame is modified, this MUST be done at the
   egress LSR only.  Note that the PW label must always be at the bottom
   of the packet's label stack, and labels MUST be allocated from the
   per-platform label space.

   This document does not specify a method for distributing the MPLS
   tunnel label or any other labels that may appear above the PW label
   on the stack.  Any acceptable method of MPLS label distribution will
   do.  This document specifies a protocol for assigning and
   distributing the PW label.  This protocol is LDP, extended as
   specified in the remainder of this document.  An LDP session must be
   set up between the pseudowire endpoints.  LDP MUST exchange PW FEC
   label bindings in downstream unsolicited mode, independent of the
   negotiated label advertisement mode of the LDP session according to
   the specifications in [RFC7358].  LDP's "liberal label retention"
   mode SHOULD be used.  However, all the LDP procedures that are
   specified in [RFC5036] and that are also applicable to this protocol
   specification MUST be implemented.

   This document requires that a receiving LSR MUST respond to a Label
   Request message with either a Label Mapping for the requested label
   or a Notification message that indicates why it cannot satisfy the
   request.  These procedures are specified in [RFC5036], Sections 3.5.7
   ("Label Mapping Message") and 3.5.8 ("Label Request Message").  Note
   that sending these responses is a stricter requirement than is
   specified in [RFC5036], but these response messages are REQUIRED to
   ensure correct operation of this protocol.

   In addition to the protocol specified herein, static assignment of PW
   labels may be used, and implementations of this protocol SHOULD
   provide support for static assignment.  PW encapsulation is always
   symmetrical in both directions of traffic along a specific PW,
   whether or not the PW uses an LDP control plane.

   This document specifies all the procedures necessary to set up and
   maintain the pseudowires needed to support "unswitched" point-to-
   point services, where each endpoint of the pseudowire is provisioned
   with the identity of the other endpoint.  There are also protocol
   mechanisms specified herein that can be used to support switched
   services and other provisioning models.  However, the use of the
   protocol mechanisms to support those other models and services is not
   described in this document.



Martini & Heron              Standards Track                    [Page 8]

RFC 8077                     PWE3 Using LDP                February 2017


5.  Details Specific to Particular Emulated Services

5.1.  IP Layer 2 Transport

   This mode carries IP packets over a pseudowire.  The encapsulation
   used is according to [RFC3032].  The PW control word MAY be inserted
   between the MPLS label stack and the IP payload.  The encapsulation
   of the IP packets for forwarding on the Attachment Circuit is
   implementation specific, is part of the native service processing
   (NSP) function [RFC3985], and is outside the scope of this document.

6.  LDP

   The PW label bindings are distributed using the LDP downstream
   unsolicited mode described in [RFC5036].  The PEs will establish an
   LDP session using the Extended Discovery mechanism described in
   Sections 2.4.2 and 2.5 of [RFC5036].

   An LDP Label Mapping message contains a FEC TLV, a Label TLV, and
   zero or more optional parameter TLVs.

   The FEC TLV is used to indicate the meaning of the label.  In the
   current context, the FEC TLV would be used to identify the particular
   pseudowire that a particular label is bound to.  In this
   specification, we define two new FEC TLVs to be used for identifying
   pseudowires.  When setting up a particular pseudowire, only one of
   these FEC TLVs is used.  The one to be used will depend on the
   particular service being emulated and on the particular provisioning
   model being supported.

   LDP allows each FEC TLV to consist of a set of FEC elements.  For
   setting up and maintaining pseudowires, however, each FEC TLV MUST
   contain exactly one FEC element.

   The LDP base specification has several kinds of label TLVs, including
   the Generic Label TLV, as specified in Section 3.4.2.1 of [RFC5036].
   For setting up and maintaining pseudowires, the Generic Label TLV
   MUST be used.

6.1.  The PWid FEC Element

   The PWid FEC Element may be used whenever both pseudowire endpoints
   have been provisioned with the same 32-bit identifier for the
   pseudowire.

   For this purpose, a new type of FEC element is defined.  The FEC
   element type is 0x80 and is defined as follows:



Martini & Heron              Standards Track                    [Page 9]

RFC 8077                     PWE3 Using LDP                February 2017


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PWid (0x80)  |C|         PW type             |PW info length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Group ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           PW ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Interface Parameter Sub-TLV                    |
   |                              "                                |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   -  Control word bit (C)

      The C-bit is used to flag the presence of a control word as
      follows:

         C = 1 control word present on this PW.
         C = 0 no control word present on this PW.

      Please see Section 7 ("Control Word") for further explanation.

   -  PW type

      A 15-bit quantity containing a value that represents the type of
      PW.  Assigned Values are specified in "IANA Allocations for
      Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].

   -  PW info length

      Length of the PW ID field and the Interface Parameter Sub-TLV
      field in octets.  If this value is 0, then it references all PWs
      using the specified Group ID, and there is no PW ID present, nor
      are there any Interface Parameter Sub-TLVs.

   -  Group ID

      An arbitrary 32-bit value that represents a group of PWs that is
      used to create groups in the PW space.  The Group ID is intended
      to be used as a port index or a virtual tunnel index.  To simplify
      configuration, a particular PW Group ID at ingress could be part
      of a Group ID assigned to the virtual tunnel for transport to the
      egress router.  The Group ID is very useful for sending wildcard
      label withdrawals or PW wildcard status Notification messages to
      remote PEs upon physical port failure.



Martini & Heron              Standards Track                   [Page 10]

RFC 8077                     PWE3 Using LDP                February 2017


   -  PW ID

      A non-zero, 32-bit connection ID that together with the PW type
      identifies a particular PW.  Note that the PW ID and the PW type
      MUST be the same at both endpoints.

   -  Interface Parameter Sub-TLV

      This variable length TLV is used to provide interface-specific
      parameters, such as Attachment Circuit MTU.

      Note that as the Interface Parameter Sub-TLV is part of the FEC,
      the rules of LDP make it impossible to change the interface
      parameters once the pseudowire has been set up.  Thus, the
      interface parameters field must not be used to pass information,
      such as status information, that may change during the life of the
      pseudowire.  Optional parameter TLVs should be used for that
      purpose.

   Using the PWid FEC, each of the two pseudowire endpoints
   independently initiates the setup of a unidirectional LSP.  An
   outgoing LSP and an incoming LSP are bound together into a single
   pseudowire if they have the same PW ID and PW type.

6.2.  The Generalized PWid FEC Element

   The PWid FEC Element can be used if a unique 32-bit value has been
   assigned to the PW and if each endpoint has been provisioned with
   that value.  The Generalized PWid FEC Element requires that the PW
   endpoints be uniquely identified; the PW itself is identified as a
   pair of endpoints.  In addition, the endpoint identifiers are
   structured to support applications where the identity of the remote
   endpoints needs to be auto-discovered rather than statically
   configured.

   The "Generalized PWid FEC Element" is FEC type 0x81.

   The Generalized PWid FEC Element does not contain anything
   corresponding to the Group ID of the PWid FEC Element.  The
   functionality of the Group ID is provided by a separate optional LDP
   TLV, the PW Group ID TLV, described in Section 6.2.2.2.  The
   interface parameters field of the PWid FEC Element is also absent;
   its functionality is replaced by the optional PW Interface Parameters
   TLV, described in Section 6.2.2.1.




Martini & Heron              Standards Track                   [Page 11]

RFC 8077                     PWE3 Using LDP                February 2017


6.2.1.  Attachment Identifiers

   As discussed in [RFC3985], a pseudowire can be thought of as
   connecting two "forwarders".  The protocol used to set up a
   pseudowire must allow the forwarder at one end of a pseudowire to
   identify the forwarder at the other end.  We use the term "Attachment
   Identifier", or "AI", to refer to the field that the protocol uses to
   identify the forwarders.  In the PWid FEC, the PWid field serves as
   the AI.  In this section, we specify a more general form of AI that
   is structured and of variable length.

   Every Forwarder in a PE must be associated with an Attachment
   Identifier (AI), either through configuration or through some
   algorithm.  The Attachment Identifier must be unique in the context
   of the PE router in which the Forwarder resides.  The combination <PE
   router IP address, AI> must be globally unique.

   It is frequently convenient to regard a set of Forwarders as being
   members of a particular "group", where PWs may only be set up among
   members of a group.  In such cases, it is convenient to identify the
   Forwarders relative to the group, so that an Attachment Identifier
   would consist of an Attachment Group Identifier (AGI) plus an
   Attachment Individual Identifier (AII).

   An Attachment Group Identifier may be thought of as a VPN-id, or a
   VLAN identifier, some attribute that is shared by all the Attachment
   PWs (or pools thereof) that are allowed to be connected.

   The details of how to construct the AGI and AII fields identifying
   the pseudowire endpoints are outside the scope of this specification.
   Different pseudowire applications, and different provisioning models,
   will require different sorts of AGI and AII fields.  The
   specification of each such application and/or model must include the
   rules for constructing the AGI and AII fields.

   As previously discussed, a (bidirectional) pseudowire consists of a
   pair of unidirectional LSPs, one in each direction.  If a particular
   pseudowire connects PE1 with PE2, the PW direction from PE1 to PE2
   can be identified as:

      <PE1, <AGI, AII1>, PE2, <AGI, AII2>>,

   and the PW direction from PE2 to PE1 can be identified by:

      <PE2, <AGI, AII2>, PE1, <AGI, AII1>>.



Martini & Heron              Standards Track                   [Page 12]

RFC 8077                     PWE3 Using LDP                February 2017


   Note that the AGI must be the same at both endpoints, but the AII
   will in general be different at each endpoint.  Thus, from the
   perspective of a particular PE, each pseudowire has a local or
   "Source AII", and a remote or "Target AII".  The pseudowire setup
   protocol can carry all three of these quantities:

   -  Attachment Group Identifier (AGI)

   -  Source Attachment Individual Identifier (SAII)

   -  Target Attachment Individual Identifier (TAII)

   If the AGI is non-null, then the Source AI (SAI) consists of the AGI
   together with the SAII, and the Target AI (TAI) consists of the TAII
   together with the AGI.  If the AGI is null, then the SAII and TAII
   are the SAI and TAI, respectively.

   The interpretation of the SAI and TAI is a local matter at the
   respective endpoint.

   The association of two unidirectional LSPs into a single
   bidirectional pseudowire depends on the SAI and the TAI.  Each
   application and/or provisioning model that uses the Generalized PWid
   FEC must specify the rules for performing this association.


Martini & Heron              Standards Track                   [Page 13]

RFC 8077                     PWE3 Using LDP                February 2017


6.2.2.  Encoding the Generalized PWid FEC Element

   FEC element type 0x81 is used.  The FEC element is encoded as
   follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Gen PWid (0x81)|C|         PW Type             |PW info length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   AGI Type    |    Length     |      Value                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                    AGI  Value (contd.)                        ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   AII Type    |    Length     |      Value                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   SAII  Value (contd.)                        ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   AII Type    |    Length     |      Value                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   TAII Value (contd.)                         ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This document does not specify the AII and AGI type field values;
   specification of the type field values to be used for a particular
   application is part of the specification of that application.  IANA
   has assigned these values using the method defined in [RFC4446].

   The SAII, TAII, and AGI are simply carried as octet strings.  The
   Length byte specifies the size of the Value field.  The null string
   can be sent by setting the Length byte to 0.  If a particular
   application does not need all three of these sub-elements, it MUST
   send all the sub-elements but set the Length to 0 for the unused sub-
   elements.

   The PW information length field contains the length of the SAII,
   TAII, and AGI, combined in octets.  If this value is 0, then it
   references all PWs using the specific Group ID (specified in the PW
   Group ID TLV).  In this case, there are no other FEC element fields
   (AGI, SAII, etc.) present, nor any PW Interface Parameters TLVs.

   Note that the interpretation of a particular field as AGI, SAII, or
   TAII depends on the order of its occurrence.  The Type field
   identifies the type of the AGI, SAII, or TAII.  When comparing two



Martini & Heron              Standards Track                   [Page 14]

RFC 8077                     PWE3 Using LDP                February 2017


   occurrences of an AGI (or SAII or TAII), the two occurrences are
   considered identical if the Type, Length, and Value fields of one are
   identical, respectively, to those of the other.

6.2.2.1.  PW Interface Parameters TLV

   This TLV MUST only be used when sending the Generalized PWid FEC.  It
   specifies interface-specific parameters.  Specific parameters, when
   applicable, MUST be used to validate that the PEs and the ingress and
   egress ports at the edges of the circuit have the necessary
   capabilities to interoperate with each other.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0|  PW Intf P. TLV (0x096B)  |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sub-TLV Type  |    Length     |    Variable Length Value      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Variable Length Value                 |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A more detailed description of this field can be found in Section 6.4
   ("Interface Parameter Sub-TLV").

6.2.2.2.  PW Group ID TLV

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0| PW Group ID TLV (0x096C)  |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Value                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The PW Group ID is an arbitrary 32-bit value that represents an
   arbitrary group of PWs.  It is used to create group PWs; for example,
   a PW Group ID can be used as a port index and assigned to all PWs
   that lead to that port.  Use of the PW Group ID enables a PE to send
   "wildcard" label withdrawals, or "wildcard" status Notification
   messages, to remote PEs upon physical port failure.

   Note Well: The PW Group ID is different from and has no relation to
   the Attachment Group Identifier.



Martini & Heron              Standards Track                   [Page 15]

RFC 8077                     PWE3 Using LDP                February 2017


   The PW Group ID TLV is not part of the FEC and will not be advertised
   except in the PW FEC advertisement.  The advertising PE MAY use the
   wildcard withdraw semantics, but the remote PEs MUST implement
   support for wildcard messages.  This TLV MUST only be used when
   sending the Generalized PWid FEC.

   To issue a wildcard command (status or withdraw):

   -  Set the PW Info Length to 0 in the Generalized PWid FEC Element.

   -  Send only the PW Group ID TLV with the FEC (no AGI/SAII/TAII is
      sent).

6.2.3.  Signaling Procedures

   In order for PE1 to begin signaling PE2, PE1 must know the address of
   the remote PE2 and a TAI.  This information may have been configured
   at PE1, or it may have been learned dynamically via some auto-
   discovery procedure.

   The egress PE (PE1), which has knowledge of the ingress PE, initiates
   the setup by sending a Label Mapping message to the ingress PE (PE2).
   The Label Mapping message contains the FEC TLV, carrying the
   Generalized PWid FEC Element (type 0x81).  The Generalized PWid FEC
   Element contains the AGI, SAII, and TAII information.

   Next, when PE2 receives such a Label Mapping message, PE2 interprets
   the message as a request to set up a PW whose endpoint (at PE2) is
   the Forwarder identified by the TAI.  From the perspective of the
   signaling protocol, exactly how PE2 maps AIs to Forwarders is a local
   matter.  In some Virtual Private Wire Service (VPWS) provisioning
   models, the TAI might, for example, be a string that identifies a
   particular Attachment Circuit, such as "ATM3VPI4VCI5", or it might,
   for example, be a string, such as "Fred", that is associated by
   configuration with a particular Attachment Circuit.  In Virtual
   Private LAN Service (VPLS), the AGI could be a VPN-id, identifying a
   particular VPLS instance.

   If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a
   Label Release message to PE1, with a Status Code of
   "Unassigned/Unrecognized TAI", and the processing of the Label
   Mapping message is complete.

   The FEC TLV sent in a Label Release message is the same as the FEC
   TLV received in the Label Mapping message being released (but without
   the interface parameter TLV).  More generally, the FEC TLV is the


Martini & Heron              Standards Track                   [Page 16]

RFC 8077                     PWE3 Using LDP                February 2017


   same in all LDP messages relating to the same PW.  In a Label Release
   message, this means that the SAII is the remote peer's AII and the
   TAII is the sender's local AII.

   If the Label Mapping message has a valid TAI, PE2 must decide whether
   to accept it.  The procedures for so deciding will depend on the
   particular type of Forwarder identified by the TAI.  Of course, the
   Label Mapping message may be rejected due to standard LDP error
   conditions as detailed in [RFC5036].

   If PE2 decides to accept the Label Mapping message, then it has to
   make sure that a PW LSP is set up in the opposite (PE1-->PE2)
   direction.  If it has already signaled for the corresponding PW LSP
   in that direction, nothing more needs to be done.  Otherwise, it must
   initiate such signaling by sending a Label Mapping message to PE1.
   This is very similar to the Label Mapping message PE2 received, but
   the SAI and TAI are reversed.

   Thus, a bidirectional PW consists of two LSPs, where the FEC of one
   has the SAII and TAII reversed with respect to the FEC of the other.

6.3.  Signaling of Pseudowire Status

6.3.1.  Use of Label Mapping Messages

   The PEs MUST send Label Mapping messages to their peers as soon as
   the PW is configured and administratively enabled, regardless of the
   Attachment Circuit state.  The PW label should not be withdrawn
   unless the operator administratively configures the pseudowire down
   (or the PW configuration is deleted entirely).  Using the procedures
   outlined in this section, a simple label withdraw method MAY also be
   supported as a legacy means of signaling PW status and AC status.  In
   any case, if the label-to-PW binding is not available, the PW MUST be
   considered in the down state.

   Once the PW status negotiation procedures are completed, if they
   result in the use of the label withdraw method for PW status
   communication, and this method is not supported by one of the PEs,
   then that PE must send a Label Release message to its peer with the
   following error:

   "Label Withdraw PW Status Method Not Supported"

   If the label withdraw method for PW status communication is selected
   for the PW, it will result in the Label Mapping message being
   advertised only if the Attachment Circuit is active.  The PW status
   signaling procedures described in this section MUST be fully
   implemented.



Martini & Heron              Standards Track                   [Page 17]

RFC 8077                     PWE3 Using LDP                February 2017


6.3.2.  Signaling PW Status

   The PE devices use an LDP TLV to indicate status to their remote
   peers.  This PW Status TLV contains more information than the
   alternative simple Label Withdraw message.

   The format of the PW Status TLV is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|     PW Status (0x096A)    |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Status Code                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The status code is a 4-octet bit field as specified in "IANA
   Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].
   The Length field specifies the length of the Status Code field in
   octets (equal to 4).

   Each bit in the Status Code field can be set individually to indicate
   more than a single failure at once.  Each fault can be cleared by
   sending an appropriate Notification message in which the respective
   bit is cleared.  The presence of the lowest bit (PW Not Forwarding)
   acts only as a generic failure indication when there is a link-down
   event for which none of the other bits apply.

   The Status TLV is transported to the remote PW peer via the LDP
   Notification message as described in [RFC5036].  The format of the
   Notification message for carrying the PW Status is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|   Notification (0x0001)     |      Message Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Message ID                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Status (TLV)                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      PW Status TLV                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           PWid FEC TLV or Generalized ID FEC TLV              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                PW Group ID TLV (Optional)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Martini & Heron              Standards Track                   [Page 18]

RFC 8077                     PWE3 Using LDP                February 2017


   The Status TLV status code is set to 0x00000028, "PW status", to
   indicate that PW status follows.  Since this notification does not
   refer to any particular message, the Message ID field is set to 0.

   The PW FEC TLV SHOULD NOT include the Interface Parameter Sub-TLVs,
   as they are ignored in the context of this message.  However, the PW
   FEC TLV MUST include the C-bit, where applicable, as it is part of
   the FEC.  When a PE's Attachment Circuit encounters an error, use of
   the PW Notification message allows the PE to send a single "wildcard"
   status message, using a PW FEC TLV with only the Group ID set, to
   denote this change in status for all affected PW connections.  This
   status message contains either the PW FEC TLV with only the Group ID
   set, or else it contains the Generalized FEC TLV with only the PW
   Group ID TLV.

   As mentioned above, the Group ID field of the PWid FEC Element, or
   the PW Group ID TLV used with the Generalized PWid FEC Element, can
   be used to send a status notification for all arbitrary sets of PWs.
   This procedure is OPTIONAL, and if it is implemented, the LDP
   Notification message should be as follows: If the PWid FEC Element is
   used, the PW information length field is set to 0, the PW ID field is
   not present, and the Interface Parameter Sub-TLVs are not present.
   If the Generalized FEC Element is used, the AGI, SAII, and TAII are
   not present, the PW information length field is set to 0, the PW
   Group ID TLV is included, and the PW Interface Parameters TLV is
   omitted.  For the purpose of this document, this is called the
   "wildcard PW status notification procedure", and all PEs implementing
   this design are REQUIRED to accept such a Notification message but
   are not required to send it.

6.3.3.  Pseudowire Status Negotiation Procedures

   When a PW is first set up, the PEs MUST attempt to negotiate the
   usage of the PW Status TLV.  This is accomplished as follows: A PE
   that supports the PW Status TLV MUST include it in the initial Label
   Mapping message following the PW FEC and the Interface Parameter Sub-
   TLVs.  The PW Status TLV will then be used for the lifetime of the
   pseudowire.  This is shown in the following diagram:



Martini & Heron              Standards Track                   [Page 19]

RFC 8077                     PWE3 Using LDP                February 2017


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                 PWid FEC or Generalized PWid FEC              +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Interface Parameters                    |
    |                              "                                |
    |                              "                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0| Generic Label (0x0200)    |      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Label                                                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|     PW Status (0x096A)    |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Status Code                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If a PW Status TLV is included in the initial Label Mapping message
   for a PW, then if the Label Mapping message from the remote PE for
   that PW does not include a PW Status TLV, or if the remote PE does
   not support the PW Status TLV, the PW will revert to the label
   withdraw method of signaling PW status.  Note that if the PW Status
   TLV is not supported by the remote peer, the peer will automatically
   ignore it, since the I (ignore) bit is set in the TLV.  The PW Status
   TLV, therefore, will not be present in the corresponding FEC
   advertisement from the remote LDP peer, which results in exactly the
   above behavior.

   If the PW Status TLV is not present following the FEC TLV in the
   initial PW Label Mapping message received by a PE, then the PW Status
   TLV will not be used, and both PEs supporting the pseudowire will
   revert to the label withdraw procedure for signaling status changes.

   If the negotiation process results in the usage of the PW Status TLV,
   then the actual PW status is determined by the PW Status TLV that was
   sent within the initial PW Label Mapping message.  Subsequent updates
   of PW status are conveyed through the Notification message.

6.4.  Interface Parameter Sub-TLV

   This field specifies interface-specific parameters.  When applicable,
   it MUST be used to validate that the PEs and the ingress and egress
   ports at the edges of the circuit have the necessary capabilities to
   interoperate with each other.  The field structure is defined as
   follows:



Martini & Heron              Standards Track                   [Page 20]

RFC 8077                     PWE3 Using LDP                February 2017


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sub-TLV Type  |    Length     |    Variable Length Value      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Variable Length Value                 |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field is defined as the length of the interface parameter
   including the Sub-TLV Type and Length field itself.  Processing of
   the interface parameters should continue when unknown interface
   parameters are encountered, and they MUST be silently ignored.

   The Interface Parameter Sub-TLV Type values are specified in "IANA
   Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].

   -  Interface MTU sub-TLV type

      A 2-octet value indicating the MTU in octets.  This is the Maximum
      Transmission Unit, excluding encapsulation overhead, of the egress
      packet interface that will be transmitting the decapsulated PDU
      that is received from the MPLS-enabled network.  This parameter is
      applicable only to PWs transporting packets and is REQUIRED for
      these PW types.  If this parameter does not match in both
      directions of a specific PW, that PW MUST NOT be enabled.

   -  Optional Interface Description string sub-TLV type

      This arbitrary, and OPTIONAL, interface description string is used
      to send a human-readable administrative string describing the
      interface to the remote PE.  This parameter is OPTIONAL and is
      applicable to all PW types.  The interface description parameter
      string length is variable and can be from 0 to 80 octets.  Human-
      readable text MUST be provided in the UTF-8 charset using the
      Default Language [RFC2277].

6.5.  LDP Label Withdrawal Procedures

   As mentioned above, the Group ID field of the PWid FEC Element, or
   the PW Group ID TLV used with the Generalized PWid FEC Element, can
   be used to withdraw all PW labels associated with a particular PW
   group.  This procedure is OPTIONAL, and if it is implemented, the LDP
   Label Withdraw message should be as follows: If the PWid FEC Element
   is used, the PW information length field is set to 0, the PW ID field
   is not present, the Interface Parameter Sub-TLVs are not present, and
   the Label TLV is not present.  If the Generalized FEC Element is
   used, the AGI, SAII, and TAII are not present, the PW information



Martini & Heron              Standards Track                   [Page 21]

RFC 8077                     PWE3 Using LDP                February 2017


   length field is set to 0, the PW Group ID TLV is included, the PW
   Interface Parameters TLV is not present, and the Label TLV is not
   present.  For the purpose of this document, this is called the
   "wildcard withdraw procedure", and all PEs implementing this design
   are REQUIRED to accept such withdraw messages but are not required to
   send it.  Note that the PW Group ID TLV only applies to PWs using the
   Generalized ID FEC Element, while the Group ID only applies to PWid
   FEC Element.

   The Interface Parameter Sub-TLVs, or TLV, MUST NOT be present in any
   LDP PW Label Withdraw or Label Release message.  A wildcard Label
   Release message MUST include only the Group ID or PW Group ID TLV.  A
   Label Release message initiated by a PE router must always include
   the PW ID.

7.  Control Word

7.1.  PW Types for Which the Control Word Is REQUIRED

   The Label Mapping messages that are sent in order to set up these PWs
   MUST have C=1.  When a Label Mapping message for a PW of one of these
   types is received and C=0, a Label Release message MUST be sent, with
   an "Illegal C-bit" status code.  In this case, the PW will not be
   enabled.

7.2.  PW Types for Which the Control Word Is NOT Mandatory

   If a system is capable of sending and receiving the control word on
   PW types for which the control word is not mandatory, then each such
   PW endpoint MUST be configurable with a parameter that specifies
   whether the use of the control word is PREFERRED or NOT PREFERRED.
   For each PW, there MUST be a default value of this parameter.  This
   specification does NOT state what the default value should be.

   If a system is NOT capable of sending and receiving the control word
   on PW types for which the control word is not mandatory, then it
   behaves exactly as if it were configured for the use of the control
   word to be NOT PREFERRED.

   If a Label Mapping message for the PW has already been received but
   no Label Mapping message for the PW has yet been sent, then the
   procedure is as follows:

        -i. If the received Label Mapping message has C=0, send a Label
            Mapping message with C=0; the control word is not used.


Martini & Heron              Standards Track                   [Page 22]

RFC 8077                     PWE3 Using LDP                February 2017


       -ii. If the received Label Mapping message has C=1, and the PW is
            locally configured such that the use of the control word is
            preferred, then send a Label Mapping message with C=1; the
            control word is used.

      -iii. If the received Label Mapping message has C=1, and the PW is
            locally configured such that the use of the control word is
            not preferred or the control word is not supported, then act
            as if no Label Mapping message for the PW had been received
            (i.e., proceed to the next paragraph).

   If a Label Mapping message for the PW has not already been received
   (or if the received Label Mapping message had C=1 and either local
   configuration says that the use of the control word is not preferred
   or the control word is not supported), then send a Label Mapping
   message in which the C-bit is set to correspond to the locally
   configured preference for use of the control word.  (That is, set C=1
   if locally configured to prefer the control word, and set C=0 if
   locally configured to prefer not to use the control word or if the
   control word is not supported).

   The next action depends on what control message is next received for
   that PW.  The possibilities are as follows:

        -i. A Label Mapping message with the same C-bit value as
            specified in the Label Mapping message that was sent.  PW
            setup is now complete, and the control word is used if C=1
            but is not used if C=0.

       -ii. A Label Mapping message with C=1, but the Label Mapping
            message that was sent has C=0.  In this case, ignore the
            received Label Mapping message and continue to wait for the
            next control message for the PW.

      -iii. A Label Mapping message with C=0, but the Label Mapping
            message that was sent has C=1.  In this case, send a Label
            Withdraw message with a "Wrong C-bit" status code, followed
            by a Label Mapping message that has C=0.  PW setup is now
            complete, and the control word is not used.

       -iv. A Label Withdraw message with the "Wrong C-bit" status code.
            Treat as a normal Label Withdraw message, but do not
            respond.  Continue to wait for the next control message for
            the PW.



Martini & Heron              Standards Track                   [Page 23]

RFC 8077                     PWE3 Using LDP                February 2017


   If at any time after a Label Mapping message has been received a
   corresponding Label Withdraw or Release is received, the action taken
   is the same as for any Label Withdraw or Release messages that might
   be received at any time.

   If both endpoints prefer the use of the control word, this procedure
   will cause it to be used.  If either endpoint prefers not to use the
   control word or does not support the control word, this procedure
   will cause it not to be used.  If one endpoint prefers to use the
   control word but the other does not, the one that prefers not to use
   it has no extra protocol to execute; it just waits for a Label
   Mapping message that has C=0.

7.3.  Control-Word Renegotiation by Label Request Message

   It is possible that after the PW C-bit negotiation procedure
   described above is complete, the local PE is re-provisioned with a
   different control word preference.  Therefore, once the control-word
   negotiation procedures are complete, the procedure can be restarted
   as follows:

        -i. If the local PE previously sent a Label Mapping message, it
            MUST send a Label Withdraw message to the remote PE and wait
            until it has received a Label Release message from the
            remote PE.

       -ii. The local PE MUST send a Label Release message to the remote
            PE for the specific label associated with the FEC that was
            advertised for this specific PW.  Note: The above-mentioned
            steps of the Label Release message and Label Withdraw
            message are not required to be executed in any specific
            sequence.

      -iii. The local PE MUST send a Label Request message to the peer
            PE and then MUST wait until it receives a Label Mapping
            message containing the remote PE's currently configured
            preference for use of the control word.

   Once the remote PE has successfully processed the Label Withdraw
   message and Label Release messages, it will reset the C-bit
   negotiation state machine and its use of the control word with the
   locally configured preference.

   From this point on, the local and remote PEs will follow the C-bit
   negotiation procedures defined in the previous section.

   The above C-bit renegotiation process SHOULD NOT be interrupted until
   it is completed, or unpredictable results might occur.



Martini & Heron              Standards Track                   [Page 24]

RFC 8077                     PWE3 Using LDP                February 2017


7.4.  Sequencing Considerations

   In the case where the router considers the sequence number field in
   the control word, it is important to note the following details when
   advertising labels.

7.4.1.  Label Advertisements

   After a label has been withdrawn by the output router and/or released
   by the input router, care must be taken not to advertise (reuse) the
   same released label until the output router can be reasonably certain
   that old packets containing the released label no longer persist in
   the MPLS-enabled network.

   This precaution is required to prevent the imposition router from
   restarting packet forwarding with a sequence number of 1 when it
   receives a Label Mapping message that binds the same FEC to the same
   label if there are still older packets in the network with a sequence
   number between 1 and 32768.  For example, if there is a packet with
   sequence number=n, where n is in the interval [1,32768] traveling
   through the network, it would be possible for the disposition router
   to receive that packet after it re-advertises the label.  Since the
   label has been released by the imposition router, the disposition
   router SHOULD be expecting the next packet to arrive with a sequence
   number of 1.  Receipt of a packet with a sequence number equal to n
   will result in n packets potentially being rejected by the
   disposition router until the imposition router imposes a sequence
   number of n+1 into a packet.  Possible methods to avoid this are for
   the disposition router always to advertise a different PW label, or
   for the disposition router to wait for a sufficient time before
   attempting to re-advertise a recently released label.  This is only
   an issue when sequence number processing is enabled at the
   disposition router.

7.4.2.  Label Release

   In situations where the imposition router wants to restart forwarding
   of packets with sequence number 1, the router shall 1) send to the
   disposition router a Label Release message, and 2) send to the
   disposition router a Label Request message.  When sequencing is
   supported, advertisement of a PW label in response to a Label Request
   message MUST also consider the issues discussed in Section 7.4.1
   ("Label Advertisements").


Martini & Heron              Standards Track                   [Page 25]

RFC 8077                     PWE3 Using LDP                February 2017


8.  IANA Considerations

8.1.  LDP TLV TYPE

   This document uses several new LDP TLV types; IANA already maintains
   a registry titled "TLV Type Name Space", defined by RFC 5036.  The
   following values have been assigned from said registry:

     TLV Type  Description
     =====================================
     0x096A    PW Status TLV
     0x096B    PW Interface Parameters TLV
     0x096C    PW Group ID TLV

8.2.  LDP Status Codes

   This document uses several new LDP status codes; IANA already
   maintains a registry titled "Status Code Name Space", defined by RFC
   5036.  The following values have been assigned:

     Range/Value     E     Description                       Reference
     ------------- -----   ----------------------            ---------
     0x00000024      0     Illegal C-Bit                     [RFC8077]
     0x00000025      0     Wrong C-Bit                       [RFC8077]
     0x00000026      0     Incompatible bit-rate             [RFC8077]
     0x00000027      0     CEP-TDM mis-configuration         [RFC8077]
     0x00000028      0     PW Status                         [RFC8077]
     0x00000029      0     Unassigned/Unrecognized TAI       [RFC8077]
     0x0000002A      0     Generic Misconfiguration Error    [RFC8077]
     0x0000002B      0     Label Withdraw PW Status          [RFC8077]
                           Method Not Supported

8.3.  FEC Type Name Space

   This document uses two new FEC element types, 0x80 and 0x81, from the
   registry "Forwarding Equivalence Class (FEC) Type Name Space" for the
   Label Distribution Protocol (LDP) [RFC5036].

9.  Security Considerations

   This document specifies the LDP extensions that are needed for
   setting up and maintaining pseudowires.  The purpose of setting up
   pseudowires is to enable Layer 2 frames to be encapsulated in MPLS
   and transmitted from one end of a pseudowire to the other.
   Therefore, we address the security considerations for both the data
   plane and the control plane.



Martini & Heron              Standards Track                   [Page 26]

RFC 8077                     PWE3 Using LDP                February 2017


9.1.  Data-Plane Security

   With regard to the security of the data plane, the following areas
   must be considered:

      - MPLS PDU inspection
      - MPLS PDU spoofing
      - MPLS PDU alteration
      - MPLS PSN protocol security
      - Access Circuit security
      - Denial-of-service prevention on the PE routers

   When an MPLS PSN is used to provide pseudowire service, there is a
   perception that security must be at least equal to the currently
   deployed Layer 2 native protocol networks that the MPLS/PW network
   combination is emulating.  This means that the MPLS-enabled network
   SHOULD be isolated from outside packet insertion in such a way that
   it SHOULD NOT be possible to insert an MPLS packet into the network
   directly.  To prevent unwanted packet insertion, it is also important
   to prevent unauthorized physical access to the PSN, as well as
   unauthorized administrative access to individual network elements.

   As mentioned above, an MPLS-enabled network should not accept MPLS
   packets from its external interfaces (i.e., interfaces to CE devices
   or to other providers' networks) unless the top label of the packet
   was legitimately distributed to the system from which the packet is
   being received.  If the packet's incoming interface leads to a
   different Service Provider (SP) (rather than to a customer), an
   appropriate trust relationship must also be present, including the
   trust that the other SP also provides appropriate security measures.

   The three main security problems faced when using an MPLS-enabled
   network to transport PWs are spoofing, alteration, and inspection.
   First, there is a possibility that the PE receiving PW PDUs will get
   a PDU that appears to be from the PE transmitting the PW into the PSN
   but that was not actually transmitted by the PE originating the PW.
   (That is, the specified encapsulations do not by themselves enable
   the decapsulator to authenticate the encapsulator.)  A second problem
   is the possibility that the PW PDU will be altered between the time
   it enters the PSN and the time it leaves the PSN (i.e., the specified
   encapsulations do not by themselves assure the decapsulator of the
   packet's integrity.)  A third problem is the possibility that the
   PDU's contents will be seen while the PDU is in transit through the
   PSN (i.e., the specification encapsulations do not ensure privacy.)
   How significant these issues are in practice depends on the security
   requirements of the applications whose traffic is being sent through
   the tunnel and how secure the PSN itself is.




Martini & Heron              Standards Track                   [Page 27]

RFC 8077                     PWE3 Using LDP                February 2017


9.2.  Control-Plane Security

   General security considerations with regard to the use of LDP are
   specified in Section 5 of [RFC5036].  Those considerations also apply
   to the case where LDP is used to set up pseudowires.

   A pseudowire connects two Attachment Circuits.  It is important to
   make sure that LDP connections are not arbitrarily accepted from
   anywhere, or else a local Attachment Circuit might get connected to
   an arbitrary remote Attachment Circuit.  Therefore, an incoming LDP
   session request MUST NOT be accepted unless its IP source address is
   known to be the source of an "eligible" LDP peer.  The set of
   eligible peers could be preconfigured (either as a list of IP
   addresses or as a list of address/mask combinations), or it could be
   discovered dynamically via an auto-discovery protocol that is itself
   trusted.  (Obviously, if the auto-discovery protocol were not
   trusted, the set of eligible peers it produces could not be trusted.)

   Even if an LDP connection request appears to come from an eligible
   peer, its source address may have been spoofed.  Therefore, some
   means of preventing source address spoofing must be in place.  For
   example, if all the eligible peers are in the same network, source
   address filtering at the border routers of that network could
   eliminate the possibility of source address spoofing.

   The LDP MD5 authentication key option, as described in Section 2.9 of
   [RFC5036], MUST be implemented, and for a greater degree of security,
   it must be used.  This provides integrity and authentication for the
   LDP messages and eliminates the possibility of source address
   spoofing.  Use of the MD5 option does not provide privacy, but
   privacy of the LDP control messages is not usually considered
   important.  As the MD5 option relies on the configuration of pre-
   shared keys, it does not provide much protection against replay
   attacks.  In addition, its reliance on pre-shared keys may make it
   very difficult to deploy when the set of eligible neighbors is
   determined by an auto-configuration protocol.

   When the Generalized PWid FEC Element is used, it is possible that a
   particular LDP peer may be one of the eligible LDP peers but may not
   be the right one to connect to the particular Attachment Circuit
   identified by the particular instance of the Generalized PWid FEC
   Element.  However, given that the peer is known to be one of the
   eligible peers (as discussed above), this would be the result of a
   configuration error rather than a security problem.  Nevertheless, it
   may be advisable for a PE to associate each of its local Attachment
   Circuits with a set of eligible peers rather than have just a single
   set of eligible peers associated with the PE as a whole.




Martini & Heron              Standards Track                   [Page 28]

RFC 8077                     PWE3 Using LDP                February 2017


10.  Interoperability and Deployment

   Section 2.2 of [RFC6410] specifies four requirements that an Internet
   Standard must meet.  This section documents how this document meets
   those requirements.

   The pseudowire technology was first deployed in 2001 and has been
   widely deployed by many carriers.  [RFC7079] documents the results of
   a survey of PW implementations with specific emphasis on control-word
   usage.  [EANTC] documents a public multi-vendor interoperability test
   of MPLS and Carrier Ethernet equipment, which included testing of
   Ethernet, ATM, and TDM pseudowires.

   The errata against [RFC4447] are generally editorial in nature and
   have been addressed in this document.

   All features in this specification have been implemented by multiple
   vendors.

   No IPR disclosures have been made to the IETF related to this
   document, to RFCs 4447 or 6723, or to the Internet-Drafts that
   resulted in RFCs 4447 and 6723.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI
              10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <http://www.rfc-editor.org/info/rfc5036>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <http://www.rfc-editor.org/info/rfc3032>.

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446, DOI
              10.17487/RFC4446, April 2006,
              <http://www.rfc-editor.org/info/rfc4446>.






Martini & Heron              Standards Track                   [Page 29]

RFC 8077                     PWE3 Using LDP                February 2017


   [RFC7358]  Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label
              Advertisement Discipline for LDP Forwarding Equivalence
              Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October
              2014, <http://www.rfc-editor.org/info/rfc7358>.

11.2.  Informative References

   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
              January 1998, <http://www.rfc-editor.org/info/rfc2277>.

   [RFC3985]  Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI
              10.17487/RFC3985, March 2005,
              <http://www.rfc-editor.org/info/rfc3985>.

   [RFC4842]  Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
              "Synchronous Optical Network/Synchronous Digital Hierarchy
              (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC
              4842, DOI 10.17487/RFC4842, April 2007,
              <http://www.rfc-editor.org/info/rfc4842>.

   [RFC4553]  Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
              Agnostic Time Division Multiplexing (TDM) over Packet
              (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
              <http://www.rfc-editor.org/info/rfc4553>.

   [RFC4619]  Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
              "Encapsulation Methods for Transport of Frame Relay over
              Multiprotocol Label Switching (MPLS) Networks", RFC 4619,
              DOI 10.17487/RFC4619, September 2006,
              <http://www.rfc-editor.org/info/rfc4619>.

   [RFC4717]  Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N.,
              Brayley, J., and G. Koleyni, "Encapsulation Methods for
              Transport of Asynchronous Transfer Mode (ATM) over MPLS
              Networks", RFC 4717, DOI 10.17487/RFC4717, December 2006,
              <http://www.rfc-editor.org/info/rfc4717>.

   [RFC4618]  Martini, L., Rosen, E., Heron, G., and A. Malis,
              "Encapsulation Methods for Transport of PPP/High-Level
              Data Link Control (HDLC) over MPLS Networks", RFC 4618,
              DOI 10.17487/RFC4618, September 2006,
              <http://www.rfc-editor.org/info/rfc4618>.



Martini & Heron              Standards Track                   [Page 30]

RFC 8077                     PWE3 Using LDP                February 2017


   [RFC4448]  Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
              "Encapsulation Methods for Transport of Ethernet over MPLS
              Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
              <http://www.rfc-editor.org/info/rfc4448>.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447, DOI
              10.17487/RFC4447, April 2006,
              <http://www.rfc-editor.org/info/rfc4447>.

   [RFC6410]  Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
              DOI 10.17487/RFC6410, October 2011,
              <http://www.rfc-editor.org/info/rfc6410>.

   [RFC6723]  Jin, L., Ed., Key, R., Ed., Delord, S., Nadeau, T., and S.
              Boutros, "Update of the Pseudowire Control-Word
              Negotiation Mechanism", RFC 6723, DOI 10.17487/RFC6723,
              September 2012, <http://www.rfc-editor.org/info/rfc6723>.

   [RFC7079]  Del Regno, N., Ed., and A. Malis, Ed., "The Pseudowire
              (PW) and Virtual Circuit Connectivity Verification (VCCV)
              Implementation Survey Results", RFC 7079, DOI
              10.17487/RFC7079, November 2013,
              <http://www.rfc-editor.org/info/rfc7079>.

   [ANSI]     American National Standards Institute, "Telecommunications
              - Synchronous Optical Network (SONET) - Basic Description
              Including Multiplex Structures, Rates, and Formats", ANSI
              T1.105, October 1995.

   [ITUG]     International Telecommunications Union, "Network node
              interface for the synchronous digital hierarchy (SDH)",
              ITU-T Recommendation G.707, May 1996.

   [EANTC]    European Advanced Networking Test Center, "MPLS and
              Carrier Ethernet: Service - Connect - Transport. Public
              Multi-Vendor Interoperability Test", February 2009.

Acknowledgments

   The authors wish to acknowledge the contributions of Vach Kompella,
   Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds.  The authors wish
   to also acknowledge the contribution of the authors of RFC 6723,
   whose work has been incorporated in this document: Lizhong Jin,
   Raymond Key, Simon Delord, Tom Nadeau, and Sami Boutros.




Martini & Heron              Standards Track                   [Page 31]

RFC 8077                     PWE3 Using LDP                February 2017


Contributors

   The following individuals were either authors or contributing authors
   for RFC 4447.  They are listed here in recognition of their work on
   that document.

   Nasser El-Aawar
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO 80021
   United States of America

   Email: nna@level3.net


   Eric C.  Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719
   United States of America

   Email: erosen@cisco.com


   Dan Tappan
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719
   United States of America

   Email: tappan@cisco.com


   Toby Smith
   Google
   6425 Penn Ave. #700
   Pittsburgh, PA 15206
   United States of America

   Email: tob@google.com


   Dimitri Vlachos
   Riverbed Technology

   Email: dimitri@riverbed.com



Martini & Heron              Standards Track                   [Page 32]

RFC 8077                     PWE3 Using LDP                February 2017


   Jayakumar Jayakumar
   Cisco Systems Inc.
   3800 Zanker Road, MS-SJ02/2
   San Jose, CA 95134
   United States of America

   Email: jjayakum@cisco.com


   Alex Hamilton,
   Cisco Systems Inc.
   485 East Tasman Drive, MS-SJC07/3
   San Jose, CA 95134
   United States of America

   Email: tahamilt@cisco.com


   Steve Vogelsang
   ECI Telecom
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   United States of America

   Email: stephen.vogelsang@ecitele.com


   John Shirron
   ECI Telecom
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   United States of America

   Email: john.shirron@ecitele.com


   Andrew G. Malis
   Verizon
   60 Sylvan Rd.
   Waltham, MA 02451
   United States of America

   Email: andrew.g.malis@verizon.com




Martini & Heron              Standards Track                   [Page 33]

RFC 8077                     PWE3 Using LDP                February 2017


   Vinai Sirkay
   Reliance Infocomm
   Dhirubai Ambani Knowledge City
   Navi Mumbai 400 709
   India

   Email: vinai@sirkay.com


   Vasile Radoaca
   Nortel Networks
   600  Technology Park
   Billerica MA 01821
   United States of America

   Email: vasile@nortelnetworks.com


   Chris Liljenstolpe
   149 Santa Monica Way
   San Francisco, CA 94127
   United States of America

   Email: ietf@cdl.asgaard.org


   Dave Cooper
   Global Crossing
   960 Hamlin Court
   Sunnyvale, CA 94089
   United States of America

   Email: dcooper@gblx.net


   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089
   United States of America

   Email: kireeti@juniper.net






Martini & Heron              Standards Track                   [Page 34]

RFC 8077                     PWE3 Using LDP                February 2017


Authors' Addresses

   Luca Martini (editor)
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO 80202
   United States of America

   Email: lmartini@monoski.com


   Giles Heron (editor)
   Cisco Systems
   10 New Square
   Bedfont Lakes
   Feltham
   Middlesex
   TW14 8HA
   United Kingdom

   Email: giheron@cisco.com


Martini & Heron              Standards Track                   [Page 35]


RFC 7761

Research, RFC, Technology
Internet Engineering Task Force (IETF)                         B. Fenner
Request for Comments: 7761                               Arista Networks
STD: 83                                                       M. Handley
Obsoletes: 4601                                                      UCL
Category: Standards Track                                    H. Holbrook
ISSN: 2070-1721                                              I. Kouvelas
                                                         Arista Networks
                                                               R. Parekh
                                                     Cisco Systems, Inc.
                                                                Z. Zhang
                                                        Juniper Networks
                                                                L. Zheng
                                                     Huawei Technologies
                                                              March 2016


         Protocol Independent Multicast - Sparse Mode (PIM-SM):
                    Protocol Specification (Revised)

Abstract

   This document specifies Protocol Independent Multicast - Sparse Mode
   (PIM-SM).  PIM-SM is a multicast routing protocol that can use the
   underlying unicast routing information base or a separate multicast-
   capable routing information base.  It builds unidirectional shared
   trees rooted at a Rendezvous Point (RP) per group, and it optionally
   creates shortest-path trees per source.

   This document obsoletes RFC 4601 by replacing it, addresses the
   errata filed against it, removes the optional (*,*,RP), PIM Multicast
   Border Router features and authentication using IPsec that lack
   sufficient deployment experience (see Appendix A), and moves the PIM
   specification to Internet Standard.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7761.




Fenner, et al.               Standards Track                    [Page 1]

RFC 7761             PIM-SM Specification (Revised)           March 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................5
   2. Terminology .....................................................5
      2.1. Definitions ................................................5
      2.2. Pseudocode Notation ........................................7
   3. PIM-SM Protocol Overview ........................................7
      3.1. Phase One: RP Tree .........................................8
      3.2. Phase Two: Register-Stop ...................................9
      3.3. Phase Three: Shortest-Path Tree ...........................10
      3.4. Source-Specific Joins .....................................10
      3.5. Source-Specific Prunes ....................................11
      3.6. Multi-Access Transit LANs .................................11
      3.7. RP Discovery ..............................................12
   4. Protocol Specification .........................................12
      4.1. PIM Protocol State ........................................13
           4.1.1. General-Purpose State ..............................14
           4.1.2. (*,G) State ........................................15
           4.1.3. (S,G) State ........................................17
           4.1.4. (S,G,rpt) State ....................................19
           4.1.5. State Summarization Macros .........................20
      4.2. Data Packet Forwarding Rules ..............................24
           4.2.1. Last-Hop Switchover to the SPT .....................27
           4.2.2. Setting and Clearing the (S,G) SPTbit ..............27
      4.3. Designated Routers (DRs) and Hello Messages ...............29
           4.3.1. Sending Hello Messages .............................29
           4.3.2. DR Election ........................................31
           4.3.3. Reducing Prune Propagation Delay on LANs ...........33
           4.3.4. Maintaining Secondary Address Lists ................36
      4.4. PIM Register Messages .....................................37
           4.4.1. Sending Register Messages from the DR ..............38
           4.4.2. Receiving Register Messages at the RP ..............43




Fenner, et al.               Standards Track                    [Page 2]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      4.5. PIM Join/Prune Messages ...................................44
           4.5.1. Receiving (*,G) Join/Prune Messages ................45
           4.5.2. Receiving (S,G) Join/Prune Messages ................50
           4.5.3. Receiving (S,G,rpt) Join/Prune Messages ............54
           4.5.4. Sending (*,G) Join/Prune Messages ..................61
           4.5.5. Sending (S,G) Join/Prune Messages ..................65
           4.5.6. (S,G,rpt) Periodic Messages ........................71
           4.5.7. State Machine for (S,G,rpt) Triggered Messages .....72
      4.6. PIM Assert Messages .......................................76
           4.6.1. (S,G) Assert Message State Machine .................77
           4.6.2. (*,G) Assert Message State Machine .................85
           4.6.3. Assert Metrics .....................................93
           4.6.4. AssertCancel Messages ..............................94
           4.6.5. Assert State Macros ................................95
      4.7. PIM Bootstrap and RP Discovery ............................98
           4.7.1. Group-to-RP Mapping ................................99
           4.7.2. Hash Function .....................................100
      4.8. Source-Specific Multicast ................................101
           4.8.1. Protocol Modifications for SSM Destination
                  Addresses .........................................102
           4.8.2. PIM-SSM-Only Routers ..............................102
      4.9. PIM Packet Formats .......................................104
           4.9.1. Encoded Source and Group Address Formats ..........105
           4.9.2. Hello Message Format ..............................108
           4.9.3. Register Message Format ...........................111
           4.9.4. Register-Stop Message Format ......................113
           4.9.5. Join/Prune Message Format .........................114
                  4.9.5.1. Group Set Source List Rules ..............117
                  4.9.5.2. Group Set Fragmentation ..................120
           4.9.6. Assert Message Format .............................121
      4.10. PIM Timers ..............................................122
      4.11. Timer Values ............................................124
   5. IANA Considerations ...........................................130
      5.1. PIM Address Family .......................................130
      5.2. PIM Hello Options ........................................130
   6. Security Considerations .......................................131
      6.1. Attacks Based on Forged Messages .........................131
           6.1.1. Forged Link-Local Messages ........................131
           6.1.2. Forged Unicast Messages ...........................132
      6.2. Non-cryptographic Authentication Mechanisms ..............132
      6.3. Authentication ...........................................133
      6.4. Denial-of-Service Attacks ................................133
   7. References ....................................................133
      7.1. Normative References .....................................133
      7.2. Informative References ...................................134
   Appendix A. Functionality Removed from RFC 4601 ..................136
   Acknowledgements .................................................136
   Authors' Addresses ...............................................136



Fenner, et al.               Standards Track                    [Page 3]

RFC 7761             PIM-SM Specification (Revised)           March 2016


List of Figures (Shown in Tabular Form)

   Figure 1. Per-(S,G) Register State Machine at a DR ................39
   Figure 2. Downstream Per-Interface (*,G) State Machine ............47
   Figure 3. Downstream Per-Interface (S,G) State Machine ............51
   Figure 4. Downstream Per-Interface (S,G,rpt) State Machine ........56
   Figure 5. Upstream (*,G) State Machine ............................62
   Figure 6. Upstream (S,G) State Machine ............................66
   Figure 7. Upstream (S,G,rpt) State Machine for Triggered
             Messages ................................................72
   Figure 8. Per-Interface (S,G) Assert State Machine ................78
   Figure 9. Per-interface (*,G) Assert State Machine ................87


Fenner, et al.               Standards Track                    [Page 4]

RFC 7761             PIM-SM Specification (Revised)           March 2016


1.  Introduction

   This document specifies a protocol for efficiently routing multicast
   groups that may span wide-area (and inter-domain) internets.  This
   protocol is called Protocol Independent Multicast - Sparse Mode
   (PIM-SM) because, although it may use the underlying unicast routing
   to provide reverse-path information for multicast tree building, it
   is not dependent on any particular unicast routing protocol.

   PIM-SM Version 2 was specified in RFC 4601 as a Proposed Standard.
   This document is intended to address the reported errata and to
   remove the optional (*,*,RP), PIM Multicast Border Router features
   and authentication using IPsec that lacks sufficient deployment
   experience, to advance PIM-SM to Internet Standard.

   This document specifies the same protocol as RFC 4601, and
   implementations per the specification in this document will be able
   to interoperate successfully with implementations per RFC 4601.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

2.1.  Definitions

   The following terms have special significance for PIM-SM:

   Rendezvous Point (RP)
      An RP is a router that has been configured to be used as the root
      of the non-source-specific distribution tree for a multicast
      group.  Join messages from receivers for a group are sent towards
      the RP, and data from senders is sent to the RP so that receivers
      can discover who the senders are and start to receive traffic
      destined for the group.

   Designated Router (DR)
      A shared-media LAN like Ethernet may have multiple PIM-SM routers
      connected to it.  A single one of these routers, the DR, will act
      on behalf of directly connected hosts with respect to the PIM-SM
      protocol.  A single DR is elected per interface (LAN or otherwise)
      using a simple election process.



Fenner, et al.               Standards Track                    [Page 5]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   MRIB
      Multicast Routing Information Base.  This is the multicast
      topology table, which is typically derived from the unicast
      routing table, or routing protocols such as Multiprotocol BGP
      (MBGP) that carry multicast-specific topology information.  In
      PIM-SM, the MRIB is used to decide where to send Join/Prune
      messages.  A secondary function of the MRIB is to provide routing
      metrics for destination addresses; these metrics are used when
      sending and processing Assert messages.

   RPF Neighbor
      RPF stands for "Reverse Path Forwarding".  The RPF Neighbor of a
      router with respect to an address is the neighbor that the MRIB
      indicates should be used to forward packets to that address.  In
      the case of a PIM-SM multicast group, the RPF neighbor is the
      router that a Join message for that group would be directed to, in
      the absence of modifying Assert state.

   TIB
      Tree Information Base.  This is the collection of state at a PIM
      router that has been created by receiving PIM Join/Prune messages,
      PIM Assert messages, and Internet Group Management Protocol (IGMP)
      or Multicast Listener Discovery (MLD) information from local
      hosts.  It essentially stores the state of all multicast
      distribution trees at that router.

   MFIB
      Multicast Forwarding Information Base.  The TIB holds all the
      state that is necessary to forward multicast packets at a router.
      However, although this specification defines forwarding in terms
      of the TIB, to actually forward packets using the TIB is very
      inefficient.  Instead, a real router implementation will normally
      build an efficient MFIB from the TIB state to perform forwarding.
      How this is done is implementation-specific and is not discussed
      in this document.

   Upstream
      Towards the root of the tree.  The root of the tree may be either
      the source or the RP, depending on the context.

   Downstream
      Away from the root of the tree.

   GenID
      Generation Identifier, used to detect reboots.



Fenner, et al.               Standards Track                    [Page 6]

RFC 7761             PIM-SM Specification (Revised)           March 2016


2.2.  Pseudocode Notation

   We use set notation in several places in this specification.

      A (+) B is the union of two sets, A and B.

      A (-) B is the elements of set A that are not in set B.

      NULL    is the empty set or list.

   In addition, we use C-like syntax:

      =       denotes assignment of a variable.

      ==      denotes a comparison for equality.

      !=      denotes a comparison for inequality.

   Braces { and } are used for grouping.

   Unless otherwise noted, operations specified by statements having
   multiple (+) and (-) operators should be evaluated from left to
   right, i.e., A (+) B (-) C is the set resulting from union of sets A
   and B minus elements in set C.

3.  PIM-SM Protocol Overview

   This section provides an overview of PIM-SM behavior.  It is intended
   as an introduction to how PIM-SM works, and it is NOT definitive.
   For the definitive specification, see Section 4.

   PIM relies on an underlying topology-gathering protocol to populate a
   routing table with routes.  This routing table is called the
   Multicast Routing Information Base (MRIB).  The routes in this table
   may be taken directly from the unicast routing table, or they may be
   different and provided by a separate routing protocol such as MBGP
   [10].  Regardless of how it is created, the primary role of the MRIB
   in the PIM protocol is to provide the next-hop router along a
   multicast-capable path to each destination subnet.  The MRIB is used
   to determine the next-hop neighbor to which any PIM Join/Prune
   message is sent.  Data flows along the reverse path of the Join
   messages.  Thus, in contrast to the unicast RIB, which specifies the
   next hop that a data packet would take to get to some subnet, the
   MRIB gives reverse-path information and indicates the path that a
   multicast data packet would take from its origin subnet to the router
   that has the MRIB.


Fenner, et al.               Standards Track                    [Page 7]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Like all multicast routing protocols that implement the service model
   from RFC 1112 [3], PIM-SM must be able to route data packets from
   sources to receivers without either the sources or receivers knowing
   a priori of the existence of the others.  This is essentially done in
   three phases, although as senders and receivers may come and go at
   any time, all three phases may occur simultaneously.

3.1.  Phase One: RP Tree

   In phase one, a multicast receiver expresses its interest in
   receiving traffic destined for a multicast group.  Typically, it does
   this using IGMP [2] or MLD [4], but other mechanisms might also serve
   this purpose.  One of the receiver's local routers is elected as the
   Designated Router (DR) for that subnet.  On receiving the receiver's
   expression of interest, the DR then sends a PIM Join message towards
   the RP for that multicast group.  This Join message is known as a
   (*,G) Join because it joins group G for all sources to that group.
   The (*,G) Join travels hop-by-hop towards the RP for the group, and
   in each router it passes through, multicast tree state for group G is
   instantiated.  Eventually, the (*,G) Join either reaches the RP or
   reaches a router that already has (*,G) Join state for that group.
   When many receivers join the group, their Join messages converge on
   the RP and form a distribution tree for group G that is rooted at the
   RP.  This is known as the RP Tree (RPT), and is also known as the
   shared tree because it is shared by all sources sending to that
   group.  Join messages are resent periodically so long as the receiver
   remains in the group.  When all receivers on a leaf-network leave the
   group, the DR will send a PIM (*,G) Prune message towards the RP for
   that multicast group.  However, if the Prune message is not sent for
   any reason, the state will eventually time out.

   A multicast data sender just starts sending data destined for a
   multicast group.  The sender's local router (DR) takes those data
   packets, unicast-encapsulates them, and sends them directly to the
   RP.  The RP receives these encapsulated data packets, decapsulates
   them, and forwards them onto the shared tree.  The packets then
   follow the (*,G) multicast tree state in the routers on the RP Tree,
   being replicated wherever the RP Tree branches, and eventually
   reaching all the receivers for that multicast group.  The process of
   encapsulating data packets to the RP is called registering, and the
   encapsulation packets are known as PIM Register packets.

   At the end of phase one, multicast traffic is flowing encapsulated to
   the RP, and then natively over the RP tree to the multicast
   receivers.



Fenner, et al.               Standards Track                    [Page 8]

RFC 7761             PIM-SM Specification (Revised)           March 2016


3.2.  Phase Two: Register-Stop

   Register-encapsulation of data packets is inefficient for two
   reasons:

   o  Encapsulation and decapsulation may be relatively expensive
      operations for a router to perform, depending on whether or not
      the router has appropriate hardware for these tasks.

   o  Traveling all the way to the RP, and then back down the shared
      tree may result in the packets traveling a relatively long
      distance to reach receivers that are close to the sender.  For
      some applications, this increased latency or bandwidth consumption
      is undesirable.

   Although Register-encapsulation may continue indefinitely, for these
   reasons, the RP will normally choose to switch to native forwarding.
   To do this, when the RP receives a register-encapsulated data packet
   from source S on group G, it will normally initiate an (S,G) source-
   specific Join towards S.  This Join message travels hop-by-hop
   towards S, instantiating (S,G) multicast tree state in the routers
   along the path.  (S,G) multicast tree state is used only to forward
   packets for group G if those packets come from source S.  Eventually
   the Join message reaches S's subnet or a router that already has
   (S,G) multicast tree state, and then packets from S start to flow
   following the (S,G) tree state towards the RP.  These data packets
   may also reach routers with (*,G) state along the path towards the
   RP; if they do, they can shortcut onto the RP tree at this point.

   While the RP is in the process of joining the source-specific tree
   for S, the data packets will continue being encapsulated to the RP.
   When packets from S also start to arrive natively at the RP, the RP
   will be receiving two copies of each of these packets.  At this
   point, the RP starts to discard the encapsulated copy of these
   packets, and it sends a Register-Stop message back to S's DR to
   prevent the DR from unnecessarily encapsulating the packets.

   At the end of phase two, traffic will be flowing natively from S
   along a source-specific tree to the RP, and from there along the
   shared tree to the receivers.  Where the two trees intersect, traffic
   may transfer from the source-specific tree to the RP tree and thus
   avoid taking a long detour via the RP.

   Note that a sender may start sending before or after a receiver joins
   the group, and thus phase two may happen before the shared tree to
   the receiver is built.


Fenner, et al.               Standards Track                    [Page 9]

RFC 7761             PIM-SM Specification (Revised)           March 2016


3.3.  Phase Three: Shortest-Path Tree

   Although having the RP join back towards the source removes the
   encapsulation overhead, it does not completely optimize the
   forwarding paths.  For many receivers, the route via the RP may
   involve a significant detour when compared with the shortest path
   from the source to the receiver.

   To obtain lower latencies or more efficient bandwidth utilization, a
   router on the receiver's LAN, typically the DR, may optionally
   initiate a transfer from the shared tree to a source-specific
   shortest-path tree (SPT).  To do this, it issues an (S,G) Join
   towards S.  This instantiates state in the routers along the path to
   S.  Eventually, this join either reaches S's subnet or reaches a
   router that already has (S,G) state.  When this happens, data packets
   from S start to flow following the (S,G) state until they reach the
   receiver.

   At this point, the receiver (or a router upstream of the receiver)
   will be receiving two copies of the data: one from the SPT and one
   from the RPT.  When the first traffic starts to arrive from the SPT,
   the DR or upstream router starts to drop the packets for G from S
   that arrive via the RP tree.  In addition, it sends an (S,G) Prune
   message towards the RP.  This is known as an (S,G,rpt) Prune.  The
   Prune message travels hop-by-hop, instantiating state along the path
   towards the RP indicating that traffic from S for G should NOT be
   forwarded in this direction.  The prune is propagated until it
   reaches the RP or a router that still needs the traffic from S for
   other receivers.

   By now, the receiver will be receiving traffic from S along the
   shortest-path tree between the receiver and S.  In addition, the RP
   is receiving the traffic from S, but this traffic is no longer
   reaching the receiver along the RP tree.  As far as the receiver is
   concerned, this is the final distribution tree.

3.4.  Source-Specific Joins

   IGMPv3 permits a receiver to join a group and specify that it only
   wants to receive traffic for a group if that traffic comes from a
   particular source.  If a receiver does this, and no other receiver on
   the LAN requires all the traffic for the group, then the DR may omit
   performing a (*,G) join to set up the shared tree, and instead issue
   a source-specific (S,G) join only.




Fenner, et al.               Standards Track                   [Page 10]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The range of multicast addresses from 232.0.0.0 to 232.255.255.255 is
   currently set aside for source-specific multicast in IPv4.  For
   groups in this range, receivers should only issue source-specific
   IGMPv3 joins.  If a PIM router receives a non-source-specific join
   for a group in this range, it should ignore it.

3.5.  Source-Specific Prunes

   IGMPv3 also permits a receiver to join a group and to specify that it
   only wants to receive traffic for a group if that traffic does not
   come from a specific source or sources.  In this case, the DR will
   perform a (*,G) join as normal, but may combine this with an
   (S,G,rpt) prune for each of the sources the receiver does not wish to
   receive.

3.6.  Multi-Access Transit LANs

   The overview so far has concerned itself with point-to-point transit
   links.  However, using multi-access LANs such as Ethernet for transit
   is not uncommon.  This can cause complications for three reasons:

   o  Two or more routers on the LAN may issue (*,G) Joins to different
      upstream routers on the LAN because they have inconsistent MRIB
      entries regarding how to reach the RP.  Both paths on the RP tree
      will be set up, causing two copies of all the shared tree traffic
      to appear on the LAN.

   o  Two or more routers on the LAN may issue (S,G) Joins to different
      upstream routers on the LAN because they have inconsistent MRIB
      entries regarding how to reach source S.  Both paths on the
      source-specific tree will be set up, causing two copies of all the
      traffic from S to appear on the LAN.

   o  A router on the LAN may issue a (*,G) Join to one upstream router
      on the LAN, and another router on the LAN may issue an (S,G) Join
      to a different upstream router on the same LAN.  Traffic from S
      may reach the LAN over both the RPT and the SPT.  If the receiver
      behind the downstream (*,G) router doesn't issue an (S,G,rpt)
      prune, then this condition would persist.

   All of these problems are caused by there being more than one
   upstream router with join state for the group or source-group pair.
   PIM does not prevent such duplicate joins from occurring; instead,
   when duplicate data packets appear on the LAN from different routers,
   these routers notice this and then elect a single forwarder.  This
   election is performed using PIM Assert messages, which resolve the
   problem in favor of the upstream router that has (S,G) state; or, if




Fenner, et al.               Standards Track                   [Page 11]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   neither router or both routers have (S,G) state, then the problem is
   resolved in favor of the router with the best metric to the RP for RP
   trees, or the best metric to the source for source-specific trees.

   These Assert messages are also received by the downstream routers on
   the LAN, and these cause subsequent Join messages to be sent to the
   upstream router that won the Assert.

3.7.  RP Discovery

   PIM-SM routers need to know the address of the RP for each group for
   which they have (*,G) state.  This address is obtained automatically
   (e.g., embedded-RP), through a bootstrap mechanism, or through static
   configuration.

   One dynamic way to do this is to use the Bootstrap Router (BSR)
   mechanism [11].  One router in each PIM domain is elected the BSR
   through a simple election process.  All the routers in the domain
   that are configured to be candidates to be RPs periodically unicast
   their candidacy to the BSR.  From the candidates, the BSR picks an
   RP-set, and periodically announces this set in a Bootstrap message.
   Bootstrap messages are flooded hop-by-hop throughout the domain until
   all routers in the domain know the RP-Set.

   To map a group to an RP, a router hashes the group address into the
   RP-set using an order-preserving hash function (one that minimizes
   changes if the RP-Set changes).  The resulting RP is the one that it
   uses as the RP for that group.

4.  Protocol Specification

   The specification of PIM-SM is broken into several parts:

   o  Section 4.1 details the protocol state stored.

   o  Section 4.2 specifies the data packet forwarding rules.

   o  Section 4.3 specifies Designated Router (DR) election and the
      rules for sending and processing Hello messages.

   o  Section 4.4 specifies the PIM Register generation and processing
      rules.

   o  Section 4.5 specifies the PIM Join/Prune generation and processing
      rules.

   o  Section 4.6 specifies the PIM Assert generation and processing
      rules.



Fenner, et al.               Standards Track                   [Page 12]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   o  Section 4.7 specifies the RP discovery mechanisms.

   o  Section 4.8 describes PIM-SSM, the subset of PIM required to
      support Source-Specific Multicast.

   o  Section 4.9 specifies the PIM packet formats.

   o  Section 4.10 provides a summary of PIM-SM timers, and Section 4.11
      provides their default values.

4.1.  PIM Protocol State

   This section specifies all the protocol state that a PIM
   implementation should maintain in order to function correctly.  We
   term this state the Tree Information Base (TIB), as it holds the
   state of all the multicast distribution trees at this router.  In
   this specification, we define PIM mechanisms in terms of the TIB.
   However, only a very simple implementation would actually implement
   packet forwarding operations in terms of this state.  Most
   implementations will use this state to build a multicast forwarding
   table, which would then be updated when the relevant state in the TIB
   changes.

   Although we specify precisely the state to be kept, this does not
   mean that an implementation of PIM-SM needs to hold the state in this
   form.  This is actually an abstract state definition, which is needed
   in order to specify the router's behavior.  A PIM-SM implementation
   is free to hold whatever internal state it requires and will still be
   conformant with this specification so long as it results in the same
   externally visible protocol behavior as an abstract router that holds
   the following state.

   We divide TIB state into three sections:

   (*,G) state
        State that maintains the RP tree for G.

   (S,G) state
        State that maintains a source-specific tree for source S and
        group G.

   (S,G,rpt) state
        State that maintains source-specific information about source S
        on the RP tree for G.  For example, if a source is being
        received on the source-specific tree, it will normally have been
        pruned off the RP tree.  This prune state is (S,G,rpt) state.



Fenner, et al.               Standards Track                   [Page 13]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The state that should be kept is described below.  Of course,
   implementations will only maintain state when it is relevant to
   forwarding operations; for example, the "NoInfo" state might be
   assumed from the lack of other state information rather than being
   held explicitly.

4.1.1.  General-Purpose State

   A router holds the following non-group-specific state:

   For each interface:

      o  Effective Override Interval

      o  Effective Propagation Delay

      o  Suppression state: One of {"Enable", "Disable"}

      Neighbor State:

         For each neighbor:

         o  Information from neighbor's Hello

         o  Neighbor's GenID.

         o  Neighbor Liveness Timer (NLT)

      Designated Router (DR) State:

         o  Designated Router's IP Address

         o  DR's DR Priority

   The Effective Override Interval, the Effective Propagation Delay, and
   the Interface suppression state are described in Section 4.3.3.
   Designated Router state is described in Section 4.3.



Fenner, et al.               Standards Track                   [Page 14]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.1.2.  (*,G) State

   For every group G, a router keeps the following state:

   (*,G) state:
        For each interface:

             Local Membership:
                  State: One of {"NoInfo", "Include"}

             PIM (*,G) Join/Prune State:

                  o  State: One of {"NoInfo" (NI), "Join" (J),
                     "Prune-Pending" (PP)}

                  o  Prune-Pending Timer (PPT)

                  o  Join/Prune Expiry Timer (ET)

             (*,G) Assert Winner State

                  o  State: One of {"NoInfo" (NI), "I lost Assert" (L),
                     "I won Assert" (W)}

                  o  Assert Timer (AT)

                  o  Assert winner's IP Address (AssertWinner)

                  o  Assert winner's Assert Metric (AssertWinnerMetric)

        Not interface specific:

             Upstream (*,G) Join/Prune State:

                  o  State: One of {"NotJoined(*,G)", "Joined(*,G)"}

             o  Upstream Join/Prune Timer (JT)

             o  Last RP Used

             o  Last RPF Neighbor towards RP that was used

   Local membership is the result of the local membership mechanism
   (such as IGMP or MLD) running on that interface.  It need not be kept
   if this router is not the DR on that interface unless this router won
   a (*,G) assert on this interface for this group, although
   implementations may optionally keep this state in case they become
   the DR or assert winner.  It is RECOMMENDED to store this information



Fenner, et al.               Standards Track                   [Page 15]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   if possible, as it reduces latency converging to stable operating
   conditions after a failure causing a change of DR.  This information
   is used by the pim_include(*,G) macro described in Section 4.1.5.

   PIM (*,G) Join/Prune state is the result of receiving PIM (*,G)
   Join/Prune messages on this interface and is specified in
   Section 4.5.1.  The state is used by the macros that calculate the
   outgoing interface list in Section 4.1.5, and in the JoinDesired(*,G)
   macro (defined in Section 4.5.4) that is used in deciding whether a
   Join(*,G) should be sent upstream.

   (*,G) Assert Winner state is the result of sending or receiving (*,G)
   Assert messages on this interface.  It is specified in Section 4.6.2.

   The upstream (*,G) Join/Prune State reflects the state of the
   upstream (*,G) state machine described in Section 4.5.4.

   The upstream (*,G) Join/Prune Timer is used to send out periodic
   Join(*,G) messages, and to override Prune(*,G) messages from peers on
   an upstream LAN interface.

   The last RP used must be stored because if the RP changes, then state
   must be torn down and rebuilt for groups whose RP changes.

   The last RPF neighbor towards the RP is stored because if the MRIB
   changes, then the RPF neighbor towards the RP may change.  If it does
   so, then we need to trigger a new Join(*,G) to the new upstream
   neighbor and a Prune(*,G) to the old upstream neighbor.  Similarly,
   if a router detects through a changed GenID in a Hello message that
   the upstream neighbor towards the RP has rebooted, then it SHOULD
   re-instantiate state by sending a Join(*,G).  These mechanisms are
   specified in Section 4.5.4



Fenner, et al.               Standards Track                   [Page 16]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.1.3.  (S,G) State

   For every source/group pair (S,G), a router keeps the following
   state:

   (S,G) state:

        For each interface:

             Local Membership:
                  State: One of {"NoInfo", "Include"}

             PIM (S,G) Join/Prune State:

                  o  State: One of {"NoInfo" (NI), "Join" (J),
                     "Prune-Pending" (PP)}

                  o  Prune-Pending Timer (PPT)

                  o  Join/Prune Expiry Timer (ET)

             (S,G) Assert Winner State

                  o  State: One of {"NoInfo" (NI), "I lost Assert" (L),
                     "I won Assert" (W)}

                  o  Assert Timer (AT)

                  o  Assert winner's IP Address (AssertWinner)

                  o  Assert winner's Assert Metric (AssertWinnerMetric)

        Not interface specific:

             Upstream (S,G) Join/Prune State:

                  o  State: One of {"NotJoined(S,G)", "Joined(S,G)"}

             o  Upstream (S,G) Join/Prune Timer (JT)

             o  Last RPF Neighbor towards S that was used

             o  SPTbit (indicates (S,G) state is active)

             o  (S,G) Keepalive Timer (KAT)






Fenner, et al.               Standards Track                   [Page 17]

RFC 7761             PIM-SM Specification (Revised)           March 2016


             Additional (S,G) state at the DR:

                  o  Register state: One of {"Join" (J), "Prune" (P),
                     "Join-Pending" (JP), "NoInfo" (NI)}

                  o  Register-Stop Timer (RST)

   Local membership is the result of the local source-specific
   membership mechanism (such as IGMP Version 3) running on that
   interface and specifying that this particular source should be
   included.  As stored here, this state is the resulting state after
   any IGMPv3 inconsistencies have been resolved.  It need not be kept
   if this router is not the DR on that interface unless this router won
   an (S,G) assert on this interface for this group.  However, it is
   RECOMMENDED to store this information if possible, as it reduces
   latency converging to stable operating conditions after a failure
   causing a change of DR.  This information is used by the
   pim_include(S,G) macro described in Section 4.1.5.

   PIM (S,G) Join/Prune state is the result of receiving PIM (S,G)
   Join/Prune messages on this interface and is specified in
   Section 4.5.2.  The state is used by the macros that calculate the
   outgoing interface list in Section 4.1.5, and in the JoinDesired(S,G)
   macro (defined in Section 4.5.5) that is used in deciding whether a
   Join(S,G) should be sent upstream.

   (S,G) Assert Winner state is the result of sending or receiving (S,G)
   Assert messages on this interface.  It is specified in Section 4.6.1.

   The upstream (S,G) Join/Prune State reflects the state of the
   upstream (S,G) state machine described in Section 4.5.5.

   The upstream (S,G) Join/Prune Timer is used to send out periodic
   Join(S,G) messages, and to override Prune(S,G) messages from peers on
   an upstream LAN interface.

   The last RPF neighbor towards S is stored because if the MRIB
   changes, then the RPF neighbor towards S may change.  If it does so,
   then we need to trigger a new Join(S,G) to the new upstream neighbor
   and a Prune(S,G) to the old upstream neighbor.  Similarly, if the
   router detects through a changed GenID in a Hello message that the
   upstream neighbor towards S has rebooted, then it SHOULD
   re-instantiate state by sending a Join(S,G).  These mechanisms are
   specified in Section 4.5.5.

   The SPTbit is used to indicate whether forwarding is taking place on
   the (S,G) Shortest Path Tree (SPT) or on the (*,G) tree.  A router
   can have (S,G) state and still be forwarding on (*,G) state during



Fenner, et al.               Standards Track                   [Page 18]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   the interval when the source-specific tree is being constructed.
   When SPTbit is FALSE, only (*,G) forwarding state is used to forward
   packets from S to G.  When SPTbit is TRUE, both (*,G) and (S,G)
   forwarding state are used.

   The (S,G) Keepalive Timer is updated by data being forwarded using
   this (S,G) forwarding state.  It is used to keep (S,G) state alive in
   the absence of explicit (S,G) Joins.  Amongst other things, this is
   necessary for the so-called "turnaround rules" -- when the RP uses
   (S,G) joins to stop encapsulation, and then (S,G) prunes to prevent
   traffic from unnecessarily reaching the RP.

   On a DR, the (S,G) Register State is used to keep track of whether to
   encapsulate data to the RP on the Register Tunnel; the (S,G)
   Register-Stop Timer tracks how long before encapsulation begins again
   for a given (S,G).

4.1.4.  (S,G,rpt) State

   For every source/group pair (S,G) for which a router also has (*,G)
   state, it also keeps the following state:

   (S,G,rpt) state:

        For each interface:

             Local Membership:
                  State: One of {"NoInfo", "Exclude"}

             PIM (S,G,rpt) Join/Prune State:

                  o  State: One of {"NoInfo", "Pruned",
                     "Prune-Pending"}

                  o  Prune-Pending Timer (PPT)

                  o  Join/Prune Expiry Timer (ET)

        Not interface specific:

             Upstream (S,G,rpt) Join/Prune State:

                  o  State: One of {"RPTNotJoined(G)",
                     "NotPruned(S,G,rpt)", "Pruned(S,G,rpt)"}

                  o  Override Timer (OT)





Fenner, et al.               Standards Track                   [Page 19]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Local membership is the result of the local source-specific
   membership mechanism (such as IGMPv3) running on that interface and
   specifying that although there is (*,G) Include state, this
   particular source should be excluded.  As stored here, this state is
   the resulting state after any IGMPv3 inconsistencies between LAN
   members have been resolved.  It need not be kept if this router is
   not the DR on that interface unless this router won a (*,G) assert on
   this interface for this group.  However, we RECOMMEND storing this
   information if possible, as it reduces latency converging to stable
   operating conditions after a failure causing a change of DR.  This
   information is used by the pim_exclude(S,G) macro described in
   Section 4.1.5.

   PIM (S,G,rpt) Join/Prune state is the result of receiving PIM
   (S,G,rpt) Join/Prune messages on this interface and is specified in
   Section 4.5.3.  The state is used by the macros that calculate the
   outgoing interface list in Section 4.1.5, and in the rules for adding
   Prune(S,G,rpt) messages to Join(*,G) messages specified in
   Section 4.5.6.

   The upstream (S,G,rpt) Join/Prune state is used along with the
   Override Timer to send the correct override messages in response to
   Join/Prune messages sent by upstream peers on a LAN.  This state and
   behavior are specified in Section 4.5.7.

4.1.5.  State Summarization Macros

   Using this state, we define the following "macro" definitions, which
   we will use in the descriptions of the state machines and pseudocode
   in the following sections.

   The most important macros are those that define the outgoing
   interface list (or "olist") for the relevant state.  An olist can be
   "immediate" if it is built directly from the state of the relevant
   type.  For example, the immediate_olist(S,G) is the olist that would
   be built if the router only had (S,G) state and no (*,G) or (S,G,rpt)
   state.  In contrast, the "inherited" olist inherits state from other
   types.  For example, the inherited_olist(S,G) is the olist that is
   relevant for forwarding a packet from S to G using both source-
   specific and group-specific state.

   There is no immediate_olist(S,G,rpt), as (S,G,rpt) state is negative
   state; it removes interfaces in the (*,G) olist from the olist that
   is actually used to forward traffic.  The inherited_olist(S,G,rpt) is
   therefore the olist that would be used for a packet from S to G
   forwarding on the RP tree.  It is a strict subset of
   immediate_olist(*,G).




Fenner, et al.               Standards Track                   [Page 20]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Generally speaking, the inherited_olists are used for forwarding, and
   the immediate_olists are used to make decisions about state
   maintenance.

   immediate_olist(*,G) =
       joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G)

   immediate_olist(S,G) =
       joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)

   inherited_olist(S,G,rpt) =
           ( joins(*,G) (-) prunes(S,G,rpt) )
       (+) ( pim_include(*,G) (-) pim_exclude(S,G))
       (-) ( lost_assert(*,G) (+) lost_assert(S,G,rpt) )

   inherited_olist(S,G) =
       inherited_olist(S,G,rpt) (+)
       joins(S,G) (+) pim_include(S,G) (-) lost_assert(S,G)

   The macros pim_include(*,G) and pim_include(S,G) indicate the
   interfaces to which traffic might be forwarded because of hosts that
   are local members on that interface.  Note that normally only the DR
   cares about local membership, but when an assert happens, the assert
   winner takes over responsibility for forwarding traffic to local
   members that have requested traffic on a group or source/group pair.

   pim_include(*,G) =
       { all interfaces I such that:
         ( ( I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
           OR AssertWinner(*,G,I) == me )
          AND  local_receiver_include(*,G,I) }

   pim_include(S,G) =
       { all interfaces I such that:
         ( (I_am_DR( I ) AND lost_assert(S,G,I) == FALSE )
           OR AssertWinner(S,G,I) == me )
          AND  local_receiver_include(S,G,I) }

   pim_exclude(S,G) =
       { all interfaces I such that:
         ( (I_am_DR( I ) AND lost_assert(*,G,I) == FALSE )
           OR AssertWinner(*,G,I) == me )
          AND  local_receiver_exclude(S,G,I) }

   The clause "local_receiver_include(S,G,I)" is true if the IGMP/MLD
   module or other local membership mechanism has determined that local
   members on interface I desire to receive traffic sent specifically by
   S to G.  "local_receiver_include(*,G,I)" is true if the IGMP/MLD



Fenner, et al.               Standards Track                   [Page 21]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   module or other local membership mechanism has determined that local
   members on interface I desire to receive all traffic sent to G
   (possibly excluding traffic from a specific set of sources).
   "local_receiver_exclude(S,G,I)" is true if
   "local_receiver_include(*,G,I)" is true but none of the local members
   desire to receive traffic from S.

   The set "joins(*,G)" is the set of all interfaces on which the router
   has received (*,G) Joins:

   joins(*,G) =
       { all interfaces I such that
         DownstreamJPState(*,G,I) is either Join or Prune-Pending }

   DownstreamJPState(*,G,I) is the state of the finite state machine in
   Section 4.5.1.

   The set "joins(S,G)" is the set of all interfaces on which the router
   has received (S,G) Joins:

   joins(S,G) =
       { all interfaces I such that
         DownstreamJPState(S,G,I) is either Join or Prune-Pending }

   DownstreamJPState(S,G,I) is the state of the finite state machine in
   Section 4.5.2.

   The set "prunes(S,G,rpt)" is the set of all interfaces on which the
   router has received (*,G) joins and (S,G,rpt) prunes:

   prunes(S,G,rpt) =
       { all interfaces I such that
         DownstreamJPState(S,G,rpt,I) is Prune or PruneTmp }

   DownstreamJPState(S,G,rpt,I) is the state of the finite state machine
   in Section 4.5.3.

   The set "lost_assert(*,G)" is the set of all interfaces on which the
   router has received (*,G) joins but has lost a (*,G) assert.  The
   macro lost_assert(*,G,I) is defined in Section 4.6.5.

   lost_assert(*,G) =
       { all interfaces I such that
         lost_assert(*,G,I) == TRUE }

   The set "lost_assert(S,G,rpt)" is the set of all interfaces on which
   the router has received (*,G) joins but has lost an (S,G) assert.
   The macro lost_assert(S,G,rpt,I) is defined in Section 4.6.5.



Fenner, et al.               Standards Track                   [Page 22]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   lost_assert(S,G,rpt) =
       { all interfaces I such that
         lost_assert(S,G,rpt,I) == TRUE }

   The set "lost_assert(S,G)" is the set of all interfaces on which the
   router has received (S,G) joins but has lost an (S,G) assert.  The
   macro lost_assert(S,G,I) is defined in Section 4.6.5.

   lost_assert(S,G) =
       { all interfaces I such that
         lost_assert(S,G,I) == TRUE }

   The following pseudocode macro definitions are also used in many
   places in the specification.  Basically, RPF' is the RPF neighbor
   towards an RP or source unless a PIM-Assert has overridden the normal
   choice of neighbor.

     neighbor RPF'(*,G) {
         if ( I_Am_Assert_Loser(*, G, RPF_interface(RP(G))) ) {
              return AssertWinner(*, G, RPF_interface(RP(G)) )
         } else {
              return NBR( RPF_interface(RP(G)), MRIB.next_hop( RP(G) ) )
         }
     }

     neighbor RPF'(S,G,rpt) {
         if( I_Am_Assert_Loser(S, G, RPF_interface(RP(G)) ) ) {
              return AssertWinner(S, G, RPF_interface(RP(G)) )
         } else {
              return RPF'(*,G)
         }
     }

     neighbor RPF'(S,G) {
         if ( I_Am_Assert_Loser(S, G, RPF_interface(S) )) {
              return AssertWinner(S, G, RPF_interface(S) )
         } else {
              return NBR( RPF_interface(S), MRIB.next_hop( S ) )
         }
     }

   RPF'(*,G) and RPF'(S,G) indicate the neighbor from which data packets
   should be coming and to which joins should be sent on the RP tree and
   SPT, respectively.

   RPF'(S,G,rpt) is basically RPF'(*,G) modified by the result of an
   Assert(S,G) on RPF_interface(RP(G)).  In such a case, packets from S
   will be originating from a different router than RPF'(*,G).  If we



Fenner, et al.               Standards Track                   [Page 23]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   only have active (*,G) Join state, we need to accept packets from
   RPF'(S,G,rpt) and add a Prune(S,G,rpt) to the periodic Join(*,G)
   messages that we send to RPF'(*,G) (see Section 4.5.6).

   The function MRIB.next_hop( S ) returns an address of the next-hop
   PIM neighbor toward the host S, as indicated by the current MRIB.  If
   S is directly adjacent, then MRIB.next_hop( S ) returns NULL.  At the
   RP for G, MRIB.next_hop( RP(G)) returns NULL.

   The function NBR( I, A ) uses information gathered through PIM Hello
   messages to map the IP address A of a directly connected PIM neighbor
   router on interface I to the primary IP address of the same router
   (Section 4.3.4).  The primary IP address of a neighbor is the address
   that it uses as the source of its PIM Hello messages.  Note that a
   neighbor's IP address may be non-unique within the PIM neighbor
   database due to scope issues.  The address must, however, be unique
   amongst the addresses of all the PIM neighbors on a specific
   interface.

   I_Am_Assert_Loser(S, G, I) is true if the Assert state machine (in
   Section 4.6.1) for (S,G) on Interface I is in "I am Assert Loser"
   state.

   I_Am_Assert_Loser(*, G, I) is true if the Assert state machine (in
   Section 4.6.2) for (*,G) on Interface I is in "I am Assert Loser"
   state.

4.2.  Data Packet Forwarding Rules

   The PIM-SM packet forwarding rules are defined below in pseudocode.

      iif is the incoming interface of the packet.

      S is the source address of the packet.

      G is the destination address of the packet (group address).

      RP is the address of the Rendezvous Point for this group.

      RPF_interface(S) is the interface the MRIB indicates would be used
         to route packets to S.

      RPF_interface(RP) is the interface the MRIB indicates would be
         used to route packets to the RP, except at the RP when it is
         the decapsulation interface (the "virtual" interface on which
         Register packets are received).





Fenner, et al.               Standards Track                   [Page 24]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   First, we restart (or start) the Keepalive Timer if the source is on
   a directly connected subnet.

   Second, we check to see if the SPTbit should be set because we've now
   switched from the RP tree to the SPT.

   Next, we check to see whether the packet should be accepted based on
   TIB state and the interface that the packet arrived on.

   If the packet should be forwarded using (S,G) state, we then build an
   outgoing interface list for the packet.  If this list is not empty,
   then we restart the (S,G) state Keepalive Timer.

   If the packet should be forwarded using (*,G) state, then we just
   build an outgoing interface list for the packet.  We also check if we
   should initiate a switch to start receiving this source on a shortest
   path tree.

   Finally, we remove the incoming interface from the outgoing interface
   list we've created, and if the resulting outgoing interface list is
   not empty, we forward the packet out of those interfaces.

   On receipt of data from S to G on interface iif:
    if( DirectlyConnected(S) == TRUE AND iif == RPF_interface(S) ) {
         set KeepaliveTimer(S,G) to Keepalive_Period
         # Note: A register state transition or UpstreamJPState(S,G)
         # transition may happen as a result of restarting
         # KeepaliveTimer, and must be dealt with here.
    }

   if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined AND
      inherited_olist(S,G) != NULL ) {
          set KeepaliveTimer(S,G) to Keepalive_Period
   }

   Update_SPTbit(S,G,iif)
   oiflist = NULL


Fenner, et al.               Standards Track                   [Page 25]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   if( iif == RPF_interface(S) AND SPTbit(S,G) == TRUE ) {
      oiflist = inherited_olist(S,G)
   } else if( iif == RPF_interface(RP(G)) AND SPTbit(S,G) == FALSE ) {
     oiflist = inherited_olist(S,G,rpt)
     CheckSwitchToSpt(S,G)
   } else {
      # Note: RPF check failed.
      # A transition in an Assert finite state machine may cause an
      # Assert(S,G) or Assert(*,G) message to be sent out interface iif.
      # See Section 4.6 for details.
      if ( SPTbit(S,G) == TRUE AND iif is in inherited_olist(S,G) ) {
         send Assert(S,G) on iif
      } else if ( SPTbit(S,G) == FALSE AND
                  iif is in inherited_olist(S,G,rpt) ) {
         send Assert(*,G) on iif
      }
   }

   oiflist = oiflist (-) iif
   forward packet on all interfaces in oiflist

   This pseudocode employs several "macro" definitions:

   DirectlyConnected(S) is TRUE if the source S is on any subnet that is
   directly connected to this router (or for packets originating on this
   router).

   inherited_olist(S,G) and inherited_olist(S,G,rpt) are defined in
   Section 4.1.

   Basically, inherited_olist(S,G) is the outgoing interface list for
   packets forwarded on (S,G) state, taking into account (*,G) state,
   asserts, etc.

   inherited_olist(S,G,rpt) is the outgoing interface list for packets
   forwarded on (*,G) state, taking into account (S,G,rpt) prune state,
   asserts, etc.

   Update_SPTbit(S,G,iif) is defined in Section 4.2.2.

   CheckSwitchToSpt(S,G) is defined in Section 4.2.1.

   UpstreamJPState(S,G) is the state of the finite state machine in
   Section 4.5.5.

   Keepalive_Period is defined in Section 4.11.



Fenner, et al.               Standards Track                   [Page 26]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Data-triggered PIM-Assert messages sent from the above forwarding
   code SHOULD be rate-limited in an implementation-dependent manner.

4.2.1.  Last-Hop Switchover to the SPT

   In Sparse-Mode PIM, last-hop routers join the shared tree towards the
   RP.  Once traffic from sources to joined groups arrives at a last-hop
   router, it has the option of switching to receive the traffic on a
   shortest path tree (SPT).

   The decision for a router to switch to the SPT is controlled as
   follows:

     void
     CheckSwitchToSpt(S,G) {
       if ( ( pim_include(*,G) (-) pim_exclude(S,G)
              (+) pim_include(S,G) != NULL )
            AND SwitchToSptDesired(S,G) ) {
              # Note: Restarting the KAT will result in the SPT switch.
              set KeepaliveTimer(S,G) to Keepalive_Period
       }
     }

   SwitchToSptDesired(S,G) is a policy function that is implementation
   defined.  An "infinite threshold" policy can be implemented by making
   SwitchToSptDesired(S,G) return false all the time.  A "switch on
   first packet" policy can be implemented by making
   SwitchToSptDesired(S,G) return true once a single packet has been
   received for the source and group.

4.2.2.  Setting and Clearing the (S,G) SPTbit

   The (S,G) SPTbit is used to distinguish whether to forward on (*,G)
   or on (S,G) state.  When switching from the RP tree to the source
   tree, there is a transition period when data is arriving due to
   upstream (*,G) state while upstream (S,G) state is being established,
   during which time a router should continue to forward only on (*,G)
   state.  This prevents temporary black holes that would be caused by
   sending a Prune(S,G,rpt) before the upstream (S,G) state has finished
   being established.




Fenner, et al.               Standards Track                   [Page 27]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:

     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP(G))
                   OR inherited_olist(S,G,rpt) == NULL
                   OR ( ( RPF'(S,G) == RPF'(*,G) ) AND
                        ( RPF'(S,G) != NULL ) )
                   OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

   Additionally, a router can set SPTbit(S,G) to TRUE in other cases,
   such as when it receives an Assert(S,G) on RPF_interface(S) (see
   Section 4.6.1).

   JoinDesired(S,G) is defined in Section 4.5.5 and indicates whether we
   have the appropriate (S,G) Join state to wish to send a Join(S,G)
   upstream.

   Basically, Update_SPTbit(S,G,iif) will set the SPTbit if we have the
   appropriate (S,G) join state, and if the packet arrived on the
   correct upstream interface for S, and if one or more of the following
   conditions apply:

   1.  The source is directly connected, in which case the switch to the
       SPT is a no-op.

   2.  The RPF interface to S is different from the RPF interface to the
       RP.  The packet arrived on RPF_interface(S), and so the SPT must
       have been completed.

   3.  No one wants the packet on the RP tree.

   4.  RPF'(S,G) == RPF'(*,G).  In this case, the router will never be
       able to tell if the SPT has been completed, so it should just
       switch immediately.  The RPF'(S,G) != NULL check ensures that the
       SPTbit is set only if the RPF neighbor towards S is valid.

   In the case where the RPF interface is the same for the RP and for S,
   but RPF'(S,G) and RPF'(*,G) differ, we wait for an Assert(S,G), which
   indicates that the upstream router with (S,G) state believes the SPT
   has been completed.  However, item (3) above is needed because there
   may not be any (*,G) state to trigger an Assert(S,G) to happen.



Fenner, et al.               Standards Track                   [Page 28]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The SPTbit is cleared in the (S,G) upstream state machine (see
   Section 4.5.5) when JoinDesired(S,G) becomes FALSE.

4.3.  Designated Routers (DRs) and Hello Messages

   A shared-media LAN like Ethernet may have multiple PIM-SM routers
   connected to it.  A single one of these routers, the DR, will act on
   behalf of directly connected hosts with respect to the PIM-SM
   protocol.  Because the distinction between LANs and point-to-point
   interfaces can sometimes be blurred, and because routers may also
   have multicast host functionality, the PIM-SM specification makes no
   distinction between the two.  Thus, DR election will happen on all
   interfaces, LAN or otherwise.

   DR election is performed using Hello messages.  Hello messages are
   also the way that option negotiation takes place in PIM, so that
   additional functionality can be enabled, or parameters tuned.

4.3.1.  Sending Hello Messages

   PIM Hello messages are sent periodically on each PIM-enabled
   interface.  They allow a router to learn about the neighboring PIM
   routers on each interface.  Hello messages are also the mechanism
   used to elect a DR, and to negotiate additional capabilities.  A
   router must record the Hello information received from each PIM
   neighbor.

   Hello messages MUST be sent on all active interfaces, including
   physical point-to-point links, and are multicast to the
   'ALL-PIM-ROUTERS' group address ('224.0.0.13' for IPv4 and 'ff02::d'
   for IPv6).

   We note that some implementations do not send Hello messages on
   point-to-point interfaces.  This is non-compliant behavior.  A
   compliant PIM router MUST send Hello messages, even on point-to-point
   interfaces.

   A per-interface Hello Timer (HT(I)) is used to trigger sending Hello
   messages on each active interface.  When PIM is enabled on an
   interface or a router first starts, the Hello Timer of that interface
   is set to a random value between 0 and Triggered_Hello_Delay.  This
   prevents synchronization of Hello messages if multiple routers are
   powered on simultaneously.  After the initial randomized interval,
   Hello messages MUST be sent every Hello_Period seconds.  The
   Hello Timer SHOULD NOT be reset except when it expires.



Fenner, et al.               Standards Track                   [Page 29]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Note that neighbors will not accept Join/Prune or Assert messages
   from a router unless they have first heard a Hello message from that
   router.  Thus, if a router needs to send a Join/Prune or Assert
   message on an interface on which it has not yet sent a Hello message
   with the currently configured IP address, then it MUST immediately
   send the relevant Hello message without waiting for the Hello Timer
   to expire, followed by the Join/Prune or Assert message.

   The DR Priority option allows a network administrator to give
   preference to a particular router in the DR election process by
   giving it a numerically larger DR Priority.  The DR Priority option
   SHOULD be included in every Hello message, even if no DR Priority is
   explicitly configured on that interface.  This is necessary because
   priority-based DR election is only enabled when all neighbors on an
   interface advertise that they are capable of using the DR Priority
   option.  The default priority is 1.

   The Generation Identifier (GenID) option SHOULD be included in all
   Hello messages.  The GenID option contains a randomly generated
   32-bit value that is regenerated each time PIM forwarding is started
   or restarted on the interface, including when the router itself
   restarts.  When a Hello message with a new GenID is received from a
   neighbor, any old Hello information about that neighbor SHOULD be
   discarded and superseded by the information from the new Hello
   message.  This may cause a new DR to be chosen on that interface.

   The LAN Prune Delay option SHOULD be included in all Hello messages
   sent on multi-access LANs.  This option advertises a router's
   capability to use values other than the defaults for the
   Propagation_Delay and Override_Interval, which affect the setting of
   the Prune-Pending, Upstream Join, and Override Timers (defined in
   Section 4.10).

   The Address List option advertises all the secondary addresses
   associated with the source interface of the router originating the
   message.  The option MUST be included in all Hello messages if there
   are secondary addresses associated with the source interface and MAY
   be omitted if no secondary addresses exist.

   To allow new or rebooting routers to learn of PIM neighbors quickly,
   when a Hello message is received from a new neighbor, or a Hello
   message with a new GenID is received from an existing neighbor, a new
   Hello message SHOULD be sent on this interface after a randomized
   delay between 0 and Triggered_Hello_Delay.  This triggered message
   need not change the timing of the scheduled periodic message.  If a
   router needs to send a Join/Prune to the new neighbor or send an
   Assert message in response to an Assert message from the new neighbor
   before this randomized delay has expired, then it MUST immediately



Fenner, et al.               Standards Track                   [Page 30]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   send the relevant Hello message without waiting for the Hello Timer
   to expire, followed by the Join/Prune or Assert message.  If it does
   not do this, then the new neighbor will discard the Join/Prune or
   Assert message.

   Before an interface goes down or changes primary IP address, a Hello
   message with a zero HoldTime SHOULD be sent immediately (with the old
   IP address if the IP address changed).  This will cause PIM neighbors
   to remove this neighbor (or its old IP address) immediately.  After
   an interface has changed its IP address, it MUST send a Hello message
   with its new IP address.  If an interface changes one of its
   secondary IP addresses, a Hello message with an updated Address List
   option and a non-zero HoldTime SHOULD be sent immediately.  This will
   cause PIM neighbors to update this neighbor's list of secondary
   addresses immediately.

4.3.2.  DR Election

   When a PIM Hello message is received on interface I, the following
   information about the sending neighbor is recorded:

      neighbor.interface
            The interface on which the Hello message arrived.

      neighbor.primary_ip_address
            The IP address that the PIM neighbor used as the source
            address of the Hello message.

      neighbor.genid
            The Generation ID of the PIM neighbor.

      neighbor.dr_priority
            The DR Priority field of the PIM neighbor, if it is present
            in the Hello message.

      neighbor.dr_priority_present
            A flag indicating if the DR Priority field was present in
            the Hello message.



Fenner, et al.               Standards Track                   [Page 31]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      neighbor.timeout
            A timer value to time out the neighbor state when it becomes
            stale, also known as the Neighbor Liveness Timer.

            The Neighbor Liveness Timer (NLT(N,I)) is reset to
            Hello_Holdtime (from the Hello Holdtime option) whenever a
            Hello message is received containing a Holdtime option, or
            to Default_Hello_Holdtime if the Hello message does not
            contain the Holdtime option.

            Neighbor state is deleted when the neighbor timeout expires.

   The function for computing the DR on interface I is:

     host
     DR(I) {
         dr = me
         for each neighbor on interface I {
             if ( dr_is_better( neighbor, dr, I ) == TRUE ) {
                 dr = neighbor
             }
         }
         return dr
     }

   The function used for comparing DR "metrics" on interface I is:

     bool
     dr_is_better(a,b,I) {
         if( there is a neighbor n on I for which n.dr_priority_present
                 is false ) {
             return a.primary_ip_address > b.primary_ip_address
         } else {
             return ( a.dr_priority > b.dr_priority ) OR
                    ( a.dr_priority == b.dr_priority AND
                      a.primary_ip_address > b.primary_ip_address )
         }
     }

   The trivial function I_am_DR(I) is defined to aid readability:

     bool
     I_am_DR(I) {
        return DR(I) == me
     }






Fenner, et al.               Standards Track                   [Page 32]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The DR Priority is a 32-bit unsigned number, and the numerically
   larger priority is always preferred.  A router's idea of the current
   DR on an interface can change when a PIM Hello message is received,
   when a neighbor times out, or when a router's own DR Priority
   changes.  If the router becomes the DR or ceases to be the DR, this
   will normally cause the DR Register state machine to change state.
   Subsequent actions are determined by that state machine.

      We note that some PIM implementations do not send Hello messages
      on point-to-point interfaces and thus cannot perform DR election
      on such interfaces.  This is non-compliant behavior.  DR election
      MUST be performed on ALL active PIM-SM interfaces.

4.3.3.  Reducing Prune Propagation Delay on LANs

   In addition to the information recorded for the DR Election, the
   following per-neighbor information is obtained from the LAN Prune
   Delay Hello option:

      neighbor.lan_prune_delay_present
            A flag indicating if the LAN Prune Delay option was present
            in the Hello message.

      neighbor.tracking_support
            A flag storing the value of the T bit in the LAN Prune Delay
            option if it is present in the Hello message.  This
            indicates the neighbor's capability to disable Join message
            suppression.

      neighbor.propagation_delay
            The Propagation Delay field of the LAN Prune Delay option
            (if present) in the Hello message.

      neighbor.override_interval
            The Override_Interval field of the LAN Prune Delay option
            (if present) in the Hello message.

   The additional state described above is deleted along with the DR
   neighbor state when the neighbor timeout expires.



Fenner, et al.               Standards Track                   [Page 33]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Just like the DR Priority option, the information provided in the LAN
   Prune Delay option is not used unless all neighbors on a link
   advertise the option.  The function below computes this state:

     bool
     lan_delay_enabled(I) {
         for each neighbor on interface I {
             if ( neighbor.lan_prune_delay_present == false ) {
                 return false
             }
         }
         return true
     }

   The Propagation Delay inserted by a router in the LAN Prune Delay
   option expresses the expected message propagation delay on the link
   and SHOULD be configurable by the system administrator.  It is used
   by upstream routers to figure out how long they should wait for a
   Join override message before pruning an interface.

   PIM implementers SHOULD enforce a lower bound on the permitted values
   for this delay to allow for scheduling and processing delays within
   their router.  Such delays may cause received messages to be
   processed later as well as triggered messages to be sent later than
   intended.  Setting this Propagation Delay to too low a value may
   result in temporary forwarding outages because a downstream router
   will not be able to override a neighbor's Prune message before the
   upstream neighbor stops forwarding.

   When all routers on a link are in a position to negotiate a
   Propagation Delay different from the default, the largest value from
   those advertised by each neighbor is chosen.  The function for
   computing the Effective Propagation Delay of interface I is:

     time_interval
     Effective_Propagation_Delay(I) {
         if ( lan_delay_enabled(I) == false ) {
             return Propagation_delay_default
         }
         delay = Propagation_Delay(I)
         for each neighbor on interface I {
             if ( neighbor.propagation_delay > delay ) {
                 delay = neighbor.propagation_delay
             }
         }
         return delay
     }



Fenner, et al.               Standards Track                   [Page 34]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   To avoid synchronization of override messages when multiple
   downstream routers share a multi-access link, the sending of such
   messages is delayed by a small random amount of time.  The period of
   randomization should represent the size of the PIM router population
   on the link.  Each router expresses its view of the amount of
   randomization necessary in the Override Interval field of the LAN
   Prune Delay option.

   When all routers on a link are in a position to negotiate an Override
   Interval different from the default, the largest value from those
   advertised by each neighbor is chosen.  The function for computing
   the Effective Override Interval of interface I is:

     time_interval
     Effective_Override_Interval(I) {
         if ( lan_delay_enabled(I) == false ) {
             return t_override_default
         }
         delay = Override_Interval(I)
         for each neighbor on interface I {
             if ( neighbor.override_interval > delay ) {
                 delay = neighbor.override_interval
             }
         }
         return delay
     }

























Fenner, et al.               Standards Track                   [Page 35]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Although the mechanisms are not specified in this document, it is
   possible for upstream routers to explicitly track the join
   membership of individual downstream routers if Join suppression is
   disabled.  A router can advertise its willingness to disable Join
   suppression by using the T bit in the LAN Prune Delay Hello option.
   Unless all PIM routers on a link negotiate this capability, explicit
   tracking and the disabling of the Join suppression mechanism are not
   possible.  The function for computing the state of Suppression on
   interface I is:

     bool
     Suppression_Enabled(I) {
         if ( lan_delay_enabled(I) == false ) {
             return true
         }
         for each neighbor on interface I {
             if ( neighbor.tracking_support == false ) {
                 return true
             }
         }
         return false
     }

   Note that the setting of Suppression_Enabled(I) affects the value of
   t_suppressed (see Section 4.11).

4.3.4.  Maintaining Secondary Address Lists

   Communication of a router's interface secondary addresses to its PIM
   neighbors is necessary to provide the neighbors with a mechanism for
   mapping next_hop information obtained through their MRIB to a primary
   address that can be used as a destination for Join/Prune messages.
   The mapping is performed through the NBR macro.  The primary address
   of a PIM neighbor is obtained from the source IP address used in its
   PIM Hello messages.  Secondary addresses are carried within the Hello
   message in an Address List Hello option.  The primary address of the
   source interface of the router MUST NOT be listed within the Address
   List Hello option.

   In addition to the information recorded for the DR Election, the
   following per-neighbor information is obtained from the Address List
   Hello option:

      neighbor.secondary_address_list
            The list of secondary addresses used by the PIM neighbor on
            the interface through which the Hello message was
            transmitted.




Fenner, et al.               Standards Track                   [Page 36]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   When processing a received PIM Hello message containing an Address
   List Hello option, the list of secondary addresses in the message
   completely replaces any previously associated secondary addresses for
   that neighbor.  If a received PIM Hello message does not contain an
   Address List Hello option, then all secondary addresses associated
   with the neighbor MUST be deleted.  If a received PIM Hello message
   contains an Address List Hello option that includes the primary
   address of the sending router in the list of secondary addresses
   (although this is not expected), then the addresses listed in the
   message, excluding the primary address, are used to update the
   associated secondary addresses for that neighbor.

   All the advertised secondary addresses in received Hello messages
   must be checked against those previously advertised by all other PIM
   neighbors on that interface.  If there is a conflict and the same
   secondary address was previously advertised by another neighbor, then
   only the most recently received mapping MUST be maintained, and an
   error message SHOULD be logged to the administrator in a rate-limited
   manner.

   Within one Address List Hello option, all the addresses MUST be of
   the same address family.  It is not permitted to mix IPv4 and IPv6
   addresses within the same message.  In addition, the address family
   of the fields in the message SHOULD be the same as the IP source and
   destination addresses of the packet header.

4.4.  PIM Register Messages

   The Designated Router (DR) on a LAN or point-to-point link
   encapsulates multicast packets from local sources to the RP for the
   relevant group unless it recently received a Register-Stop message
   for that (S,G) or (*,G) from the RP.  When the DR receives a
   Register-Stop message from the RP, it starts a Register-Stop Timer to
   maintain this state.  Just before the Register-Stop Timer expires,
   the DR sends a Null-Register message to the RP to allow the RP to
   refresh the Register-Stop information at the DR.  If the
   Register-Stop Timer actually expires, the DR will resume
   encapsulating packets from the source to the RP.













Fenner, et al.               Standards Track                   [Page 37]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.4.1.  Sending Register Messages from the DR

   Every PIM-SM router has the capability to be a DR.  The state machine
   below is used to implement Register functionality.  For the purposes
   of specification, we represent the mechanism to encapsulate packets
   to the RP as a Register-Tunnel interface, which is added to or
   removed from the (S,G) olist.  The tunnel interface then takes part
   in the normal packet forwarding rules as specified in Section 4.2.

   If register state is maintained, it is maintained only for directly
   connected sources and is per-(S,G).  There are four states in the
   DR's per-(S,G) Register state machine:

      Join (J)
            The register tunnel is "joined" (the join is actually
            implicit, but the DR acts as if the RP has joined the DR on
            the tunnel interface).

      Prune (P)
            The register tunnel is "pruned" (this occurs when a
            Register-Stop is received).

      Join-Pending (JP)
            The register tunnel is pruned but the DR is contemplating
            adding it back.

      NoInfo (NI)
            No information.  This is the initial state, and the state
            when the router is not the DR.

   In addition, a Register-Stop Timer (RST) is kept if the state machine
   is not in the NoInfo state.



















Fenner, et al.               Standards Track                   [Page 38]

RFC 7761             PIM-SM Specification (Revised)           March 2016


           Figure 1: Per-(S,G) Register State Machine at a DR

+----------++----------------------------------------------------------+
|          ||                          Event                           |
|          ++----------+-----------+-----------+-----------+-----------+
|Prev State||Register- | Could     | Could     | Register- | RP changed|
|          ||Stop Timer| Register  | Register  | Stop      |           |
|          ||expires   | ->True    | ->False   | received  |           |
+----------++----------+-----------+-----------+-----------+-----------+
|NoInfo    ||-         | -> J state| -         | -         | -         |
|(NI)      ||          | add reg   |           |           |           |
|          ||          | tunnel    |           |           |           |
+----------++----------+-----------+-----------+-----------+-----------+
|          ||-         | -         | -> NI     | -> P state| -> J state|
|          ||          |           | state     |           |           |
|          ||          |           | remove reg| remove reg| update reg|
|Join (J)  ||          |           | tunnel    | tunnel;   | tunnel    |
|          ||          |           |           | set       |           |
|          ||          |           |           | Register- |           |
|          ||          |           |           | Stop      |           |
|          ||          |           |           | Timer(*)  |           |
+----------++----------+-----------+-----------+-----------+-----------+
|          ||-> J state| -         | -> NI     | -> P state| -> J state|
|          ||          |           | state     |           |           |
|Join-     ||add reg   |           |           | set       | add reg   |
|Pending   ||tunnel    |           |           | Register- | tunnel;   |
|(JP)      ||          |           |           | Stop      | cancel    |
|          ||          |           |           | Timer(*)  | Register- |
|          ||          |           |           |           | Stop Timer|
+----------++----------+-----------+-----------+-----------+-----------+
|          ||-> JP     | -         | -> NI     | -         | -> J state|
|          ||state     |           | state     |           |           |
|          ||set       |           |           |           | add reg   |
|Prune (P) ||Register- |           |           |           | tunnel;   |
|          ||Stop      |           |           |           | cancel    |
|          ||Timer(**);|           |           |           | Register- |
|          ||send Null-|           |           |           | Stop Timer|
|          ||Register  |           |           |           |           |
+----------++----------+-----------+-----------+-----------+-----------+












Fenner, et al.               Standards Track                   [Page 39]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Notes:

   (*)  The Register-Stop Timer is set to a random value chosen
        uniformly from the interval ( 0.5 * Register_Suppression_Time,
        1.5 * Register_Suppression_Time) minus Register_Probe_Time.

        Subtracting off Register_Probe_Time is a bit unnecessary because
        it is really small compared to Register_Suppression_Time, but
        this was in the old specification and is kept for compatibility.

   (**) The Register-Stop Timer is set to Register_Probe_Time.

   The following three actions are defined:

   Add Register Tunnel

      A Register-Tunnel virtual interface, VI, is created (if it doesn't
      already exist) with its encapsulation target being RP(G).
      DownstreamJPState(S,G,VI) is set to Join state, causing the tunnel
      interface to be added to immediate_olist(S,G) and
      inherited_olist(S,G).

   Remove Register Tunnel

      VI is the Register-Tunnel virtual interface with encapsulation
      target of RP(G).  DownstreamJPState(S,G,VI) is set to NoInfo
      state, causing the tunnel interface to be removed from
      immediate_olist(S,G) and inherited_olist(S,G).  If
      DownstreamJPState(S,G,VI) is NoInfo for all (S,G), then VI can be
      deleted.

   Update Register Tunnel

      This action occurs when RP(G) changes.

      VI_old is the Register-Tunnel virtual interface with encapsulation
      target old_RP(G).  A Register-Tunnel virtual interface, VI_new, is
      created (if it doesn't already exist) with its encapsulation
      target being new_RP(G).  DownstreamJPState(S,G,VI_old) is set to
      NoInfo state, and DownstreamJPState(S,G,VI_new) is set to Join
      state.  If DownstreamJPState(S,G,VI_old) is NoInfo for all (S,G),
      then VI_old can be deleted.

      Note that we cannot simply change the encapsulation target of
      VI_old because not all groups using that encapsulation tunnel will
      have moved to the same new RP.





Fenner, et al.               Standards Track                   [Page 40]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   CouldRegister(S,G)

      The macro "CouldRegister" in the state machine is defined as:

         bool CouldRegister(S,G) {
            return ( I_am_DR( RPF_interface(S) ) AND
                     KeepaliveTimer(S,G) is running AND
                     DirectlyConnected(S) == TRUE )
         }

      Note that on reception of a packet at the DR from a directly
      connected source, KeepaliveTimer(S,G) needs to be set by the
      packet forwarding rules before computing CouldRegister(S,G) in the
      register state machine, or the first packet from a source won't be
      registered.

   Encapsulating Data Packets in the Register Tunnel

      Conceptually, the Register Tunnel is an interface with a smaller
      MTU than the underlying IP interface towards the RP.  IP
      fragmentation on packets forwarded on the Register Tunnel is
      performed based upon this smaller MTU.  The encapsulating DR may
      perform Path MTU Discovery to the RP to determine the effective
      MTU of the tunnel.  Fragmentation for the smaller MTU should take
      both the outer IP header and the PIM register header overhead into
      account.  If a multicast packet is fragmented on the way into the
      Register Tunnel, each fragment is encapsulated individually so it
      contains IP, PIM, and inner IP headers.

      In IPv6, the DR MUST perform Path MTU Discovery, and an ICMP
      Packet Too Big message MUST be sent by the encapsulating DR if it
      receives a packet that will not fit in the effective MTU of the
      tunnel.  If the MTU between the DR and the RP results in the
      effective tunnel MTU being smaller than 1280 (the IPv6 minimum
      MTU), the DR MUST send Fragmentation Required messages with an MTU
      value of 1280 and MUST fragment its PIM register messages as
      required, using an IPv6 fragmentation header between the outer
      IPv6 header and the PIM Register header.

      The TTL of a forwarded data packet is decremented before it is
      encapsulated in the Register Tunnel.  The encapsulating packet
      uses the normal TTL that the router would use for any locally
      generated IP packet.

      The IP Explicit Congestion Notification (ECN) bits should be
      copied from the original packet to the IP header of the
      encapsulating packet.  They SHOULD NOT be set independently by the
      encapsulating router.



Fenner, et al.               Standards Track                   [Page 41]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      The Diffserv Code Point (DSCP) should be copied from the original
      packet to the IP header of the encapsulating packet.  It MAY be
      set independently by the encapsulating router, based upon static
      configuration or traffic classification.  See [12] for more
      discussion on setting the DSCP on tunnels.

   Handling Register-Stop(*,G) Messages at the DR

      An old RP might send a Register-Stop message with the source
      address set to all zeros.  This was the normal course of action in
      RFC 2362 when the Register message matched against (*,G) state at
      the RP, and it was defined as meaning "stop encapsulating all
      sources for this group".  However, the behavior of such a
      Register-Stop(*,G) is ambiguous or incorrect in some
      circumstances.

      We specify that an RP should not send Register-Stop(*,G) messages,
      but for compatibility, a DR should be able to accept one if it is
      received.

      A Register-Stop(*,G) should be treated as a Register-Stop(S,G) for
      all (S,G) Register state machines that are not in the NoInfo
      state.  A router should not apply a Register-Stop(*,G) to sources
      that become active after the Register-Stop(*,G) was received.



























Fenner, et al.               Standards Track                   [Page 42]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.4.2.  Receiving Register Messages at the RP

   When an RP receives a Register message, the course of action is
   decided according to the following pseudocode:

   packet_arrives_on_rp_tunnel( pkt ) {
       if( outer.dst is not one of my addresses ) {
           drop the packet silently.
           # Note: This may be a spoofing attempt.
       }
       if( I_am_RP(G) AND outer.dst == RP(G) ) {
             sentRegisterStop = FALSE;
             if ( SPTbit(S,G) OR
              ( SwitchToSptDesired(S,G) AND
                ( inherited_olist(S,G) == NULL ))) {
               send Register-Stop(S,G) to outer.src
               sentRegisterStop = TRUE;
             }
             if ( SPTbit(S,G) OR SwitchToSptDesired(S,G) ) {
                  if ( sentRegisterStop == TRUE ) {
                       set KeepaliveTimer(S,G) to RP_Keepalive_Period;
                  } else {
                       set KeepaliveTimer(S,G) to Keepalive_Period;
                  }
             }
             if( !SPTbit(S,G) AND ! pkt.NullRegisterBit ) {
                  decapsulate and forward the inner packet to
                  inherited_olist(S,G,rpt) # Note (+)
             }
       } else {
           send Register-Stop(S,G) to outer.src
           # Note (*)
       }
   }

   outer.dst is the IP destination address of the encapsulating header.

   outer.src is the IP source address of the encapsulating header, i.e.,
   the DR's address.

   I_am_RP(G) is true if the group-to-RP mapping indicates that this
   router is the RP for the group.

   Note (*): This may block traffic from S for Register_Suppression_Time
             if the DR learned about a new group-to-RP mapping before
             the RP did.  However, this doesn't matter unless we figure
             out some way for the RP also to accept (*,G) joins when it
             doesn't yet realize that it is about to become the RP



Fenner, et al.               Standards Track                   [Page 43]

RFC 7761             PIM-SM Specification (Revised)           March 2016


             for G.  This will all get sorted out once the RP learns the
             new group-to-RP mapping.  We decided to do nothing about
             this and just accept the fact that PIM may suffer
             interrupted (*,G) connectivity following an RP change.

   Note (+): Implementations SHOULD NOT make this a special case, but
             SHOULD arrange that this path rejoin the normal packet
             forwarding path.  All of the appropriate actions from the
             "On receipt of data from S to G on interface iif"
             pseudocode in Section 4.2 should be performed.

   KeepaliveTimer(S,G) is restarted at the RP when packets arrive on the
   proper tunnel interface and the RP desires to switch to the SPT or
   the SPTbit is already set.  This may cause the upstream (S,G) state
   machine to trigger a join if the inherited_olist(S,G) is not NULL.

   An RP should preserve (S,G) state that was created in response to a
   Register message for at least ( 3 * Register_Suppression_Time );
   otherwise, the RP may stop joining (S,G) before the DR for S has
   restarted sending registers.  Traffic would then be interrupted until
   the Register-Stop Timer expires at the DR.

   Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
   Register_Suppression_Time + Register_Probe_Time ).

   When forwarding a packet from the Register Tunnel, the TTL of the
   original data packet is decremented after it is decapsulated.

   The IP ECN bits should be copied from the IP header of the Register
   packet to the decapsulated packet.

   The DSCP should be copied from the IP header of the Register packet
   to the decapsulated packet.  The RP MAY retain the DSCP of the inner
   packet or re-classify the packet and apply a different DSCP.
   Scenarios where each of these might be useful are discussed in [12].

4.5.  PIM Join/Prune Messages

   A PIM Join/Prune message consists of a list of groups and a list of
   Joined and Pruned sources for each group.  When processing a received
   Join/Prune message, each Joined or Pruned source for a group is
   effectively considered individually, and applies to one or more of
   the following state machines.  When considering a Join/Prune message
   whose Upstream Neighbor Address field addresses this router, (*,G)
   Joins and Prunes can affect both the (*,G) and (S,G,rpt) downstream
   state machines, while (S,G), and (S,G,rpt) Joins and Prunes can only
   affect their respective downstream state machines.  When considering




Fenner, et al.               Standards Track                   [Page 44]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   a Join/Prune message whose Upstream Neighbor Address field addresses
   another router, most Join or Prune messages could affect each
   upstream state machine.

   In general, a PIM Join/Prune message should only be accepted for
   processing if it comes from a known PIM neighbor.  A PIM router hears
   about PIM neighbors through PIM Hello messages.  If a router receives
   a Join/Prune message from a particular IP source address and it has
   not seen a PIM Hello message from that source address, then the
   Join/Prune message SHOULD be discarded without further processing.
   In addition, if the Hello message from a neighbor was authenticated
   (see Section 6.3), then all Join/Prune messages from that neighbor
   MUST also be authenticated.

   We note that some older PIM implementations incorrectly fail to send
   Hello messages on point-to-point interfaces, so we also RECOMMEND
   that a configuration option be provided to allow interoperation with
   such older routers, but that this configuration option SHOULD NOT be
   enabled by default.

4.5.1.  Receiving (*,G) Join/Prune Messages

   When a router receives a Join(*,G), it must first check to see
   whether the RP in the message matches RP(G) (the router's idea of who
   the RP is).  If the RP in the message does not match RP(G), the
   Join(*,G) should be silently dropped.  (Note that other source list
   entries, such as (S,G,rpt) or (S,G), in the same Group-Specific Set
   should still be processed.)  If a router has no RP information (e.g.,
   has not recently received a BSR message), then it may choose to
   accept Join(*,G) and treat the RP in the message as RP(G).  Received
   Prune(*,G) messages are processed even if the RP in the message does
   not match RP(G).



















Fenner, et al.               Standards Track                   [Page 45]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The per-interface state machine for receiving (*,G) Join/Prune
   messages is given below.  There are three states:

      NoInfo (NI)
            The interface has no (*,G) Join state and no timers running.

      Join (J)
            The interface has (*,G) Join state, which will cause the
            router to forward packets destined for G from this interface
            except if there is also (S,G,rpt) prune information (see
            Section 4.5.3) or the router lost an assert on this
            interface.

      Prune-Pending (PP)
            The router has received a Prune(*,G) on this interface from
            a downstream neighbor and is waiting to see whether the
            prune will be overridden by another downstream router.  For
            forwarding purposes, the Prune-Pending state functions
            exactly like the Join state.

   In addition, the state machine uses two timers:

      Expiry Timer (ET)
            This timer is restarted when a valid Join(*,G) is received.
            Expiry of the Expiry Timer causes the interface state to
            revert to NoInfo for this group.

      Prune-Pending Timer (PPT)
            This timer is set when a valid Prune(*,G) is received.
            Expiry of the Prune-Pending Timer causes the interface state
            to revert to NoInfo for this group.




















Fenner, et al.               Standards Track                   [Page 46]

RFC 7761             PIM-SM Specification (Revised)           March 2016


         Figure 2: Downstream Per-Interface (*,G) State Machine

+------------++--------------------------------------------------------+
|            ||                         Event                          |
|            ++-------------+--------------+-------------+-------------+
|Prev State  ||Receive      | Receive      | Prune-      | Expiry Timer|
|            ||Join(*,G)    | Prune(*,G)   | Pending     | Expires     |
|            ||             |              | Timer       |             |
|            ||             |              | Expires     |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> NI state  | -           | -           |
|NoInfo (NI) ||start Expiry |              |             |             |
|            ||Timer        |              |             |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> PP state  | -           | -> NI state |
|Join (J)    ||restart      | start Prune- |             |             |
|            ||Expiry Timer | Pending      |             |             |
|            ||             | Timer        |             |             |
+------------++-------------+--------------+-------------+-------------+
|Prune-      ||-> J state   | -> PP state  | -> NI state | -> NI state |
|Pending (PP)||restart      |              | Send Prune- |             |
|            ||Expiry Timer |              | Echo(*,G)   |             |
+------------++-------------+--------------+-------------+-------------+

   The transition events "Receive Join(*,G)" and "Receive Prune(*,G)"
   imply receiving a Join or Prune targeted to this router's primary IP
   address on the received interface.  If the upstream neighbor address
   field is not correct, these state transitions in this state machine
   MUST NOT occur, although seeing such a packet may cause state
   transitions in other state machines.

   On unnumbered interfaces on point-to-point links, the router's
   address should be the same as the source address it chose for the
   Hello message it sent over that interface.  However, on point-to-
   point links it is RECOMMENDED that for backwards compatibility PIM
   Join/Prune messages with an upstream neighbor address field of all
   zeros also be accepted.














Fenner, et al.               Standards Track                   [Page 47]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from NoInfo State

   When in NoInfo state, the following event may trigger a transition:

      Receive Join(*,G)
            A Join(*,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (*,G) downstream state machine on interface I
            transitions to the Join state.  The Expiry Timer (ET) is
            started and set to the HoldTime from the triggering
            Join/Prune message.

   Transitions from Join State

   When in Join state, the following events may trigger a transition:

      Receive Join(*,G)
            A Join(*,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (*,G) downstream state machine on interface I remains in
            Join state, and the Expiry Timer (ET) is restarted.  The ET
            is set to the maximum of its current value and the HoldTime
            from the triggering Join/Prune message.

      Receive Prune(*,G)
            A Prune(*,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (*,G) downstream state machine on interface I
            transitions to the Prune-Pending state.  The
            Prune-Pending Timer is started.  It is set to the
            J/P_Override_Interval(I) if the router has more than one
            neighbor on that interface; otherwise, it is set to zero,
            causing it to expire immediately.

      Expiry Timer Expires
            The Expiry Timer for the (*,G) downstream state machine on
            interface I expires.

            The (*,G) downstream state machine on interface I
            transitions to the NoInfo state.





Fenner, et al.               Standards Track                   [Page 48]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from Prune-Pending State

   When in Prune-Pending state, the following events may trigger a
   transition:

      Receive Join(*,G)
            A Join(*,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (*,G) downstream state machine on interface I
            transitions to the Join state.  The Prune-Pending Timer is
            canceled (without triggering an expiry event).  The
            Expiry Timer (ET) is restarted and is then set to the
            maximum of its current value and the HoldTime from the
            triggering Join/Prune message.

      Expiry Timer Expires
            The Expiry Timer for the (*,G) downstream state machine on
            interface I expires.

            The (*,G) downstream state machine on interface I
            transitions to the NoInfo state.

      Prune-Pending Timer Expires
            The Prune-Pending Timer for the (*,G) downstream state
            machine on interface I expires.

            The (*,G) downstream state machine on interface I
            transitions to the NoInfo state.  A PruneEcho(*,G) is sent
            onto the subnet connected to interface I.

            The action "Send PruneEcho(*,G)" is triggered when the
            router stops forwarding on an interface as a result of a
            prune.  A PruneEcho(*,G) is simply a Prune(*,G) message sent
            by the upstream router on a LAN with its own address in the
            Upstream Neighbor Address field.  Its purpose is to add
            additional reliability so that if a Prune that should have
            been overridden by another router is lost locally on the
            LAN, then the PruneEcho may be received and cause the
            override to happen.  A PruneEcho(*,G) need not be sent on an
            interface that contains only a single PIM neighbor during
            the time this state machine was in Prune-Pending state.








Fenner, et al.               Standards Track                   [Page 49]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.5.2.  Receiving (S,G) Join/Prune Messages

   The per-interface state machine for receiving (S,G) Join/Prune
   messages is given below and is almost identical to that for (*,G)
   messages.  There are three states:

      NoInfo (NI)
            The interface has no (S,G) Join state and no (S,G) timers
            running.

      Join (J)
            The interface has (S,G) Join state, which will cause the
            router to forward packets from S destined for G from this
            interface if the (S,G) state is active (the SPTbit is set)
            except if the router lost an assert on this interface.

      Prune-Pending (PP)
            The router has received a Prune(S,G) on this interface from
            a downstream neighbor and is waiting to see whether the
            prune will be overridden by another downstream router.  For
            forwarding purposes, the Prune-Pending state functions
            exactly like the Join state.

   In addition, there are two timers:

      Expiry Timer (ET)
            This timer is set when a valid Join(S,G) is received.
            Expiry of the Expiry Timer causes this state machine to
            revert to NoInfo state.

      Prune-Pending Timer (PPT)
            This timer is set when a valid Prune(S,G) is received.
            Expiry of the Prune-Pending Timer causes this state machine
            to revert to NoInfo state.

















Fenner, et al.               Standards Track                   [Page 50]

RFC 7761             PIM-SM Specification (Revised)           March 2016


         Figure 3: Downstream Per-Interface (S,G) State Machine

+------------++--------------------------------------------------------+
|            ||                         Event                          |
|            ++-------------+--------------+-------------+-------------+
|Prev State  ||Receive      | Receive      | Prune-      | Expiry Timer|
|            ||Join(S,G)    | Prune(S,G)   | Pending     | Expires     |
|            ||             |              | Timer       |             |
|            ||             |              | Expires     |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> NI state  | -           | -           |
|NoInfo (NI) ||start Expiry |              |             |             |
|            ||Timer        |              |             |             |
+------------++-------------+--------------+-------------+-------------+
|            ||-> J state   | -> PP state  | -           | -> NI state |
|Join (J)    ||restart      | start Prune- |             |             |
|            ||Expiry Timer | Pending      |             |             |
|            ||             | Timer        |             |             |
+------------++-------------+--------------+-------------+-------------+
|Prune-      ||-> J state   | -> PP state  | -> NI state | -> NI state |
|Pending (PP)||restart      |              | Send Prune- |             |
|            ||Expiry Timer |              | Echo(S,G)   |             |
+------------++-------------+--------------+-------------+-------------+

   The transition events "Receive Join(S,G)" and "Receive Prune(S,G)"
   imply receiving a Join or Prune targeted to this router's primary IP
   address on the received interface.  If the upstream neighbor address
   field is not correct, these state transitions in this state machine
   MUST NOT occur, although seeing such a packet may cause state
   transitions in other state machines.

   On unnumbered interfaces on point-to-point links, the router's
   address SHOULD be the same as the source address it chose for the
   Hello message it sent over that interface.  However, on point-to-
   point links it is RECOMMENDED that for backwards compatibility PIM
   Join/Prune messages with an upstream neighbor address field of all
   zeros also be accepted.














Fenner, et al.               Standards Track                   [Page 51]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from NoInfo State

   When in NoInfo state, the following event may trigger a transition:

      Receive Join(S,G)
            A Join(S,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G) downstream state machine on interface I
            transitions to the Join state.  The Expiry Timer (ET) is
            started and set to the HoldTime from the triggering
            Join/Prune message.

   Transitions from Join State

   When in Join state, the following events may trigger a transition:

      Receive Join(S,G)
            A Join(S,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G) downstream state machine on interface I remains in
            Join state.  The Expiry Timer (ET) is restarted and is then
            set to the maximum of its current value and the HoldTime
            from the triggering Join/Prune message.

      Receive Prune(S,G)
            A Prune(S,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G) downstream state machine on interface I
            transitions to the Prune-Pending state.  The
            Prune-Pending Timer is started.  It is set to the
            J/P_Override_Interval(I) if the router has more than one
            neighbor on that interface; otherwise, it is set to zero,
            causing it to expire immediately.

      Expiry Timer Expires
            The Expiry Timer for the (S,G) downstream state machine on
            interface I expires.

            The (S,G) downstream state machine on interface I
            transitions to the NoInfo state.





Fenner, et al.               Standards Track                   [Page 52]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from Prune-Pending State

   When in Prune-Pending state, the following events may trigger a
   transition:

      Receive Join(S,G)
            A Join(S,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G) downstream state machine on interface I
            transitions to the Join state.  The Prune-Pending Timer is
            canceled (without triggering an expiry event).  The
            Expiry Timer (ET) is restarted and is then set to the
            maximum of its current value and the HoldTime from the
            triggering Join/Prune message.

      Expiry Timer Expires
            The Expiry Timer for the (S,G) downstream state machine on
            interface I expires.

            The (S,G) downstream state machine on interface I
            transitions to the NoInfo state.

      Prune-Pending Timer Expires
            The Prune-Pending Timer for the (S,G) downstream state
            machine on interface I expires.

            The (S,G) downstream state machine on interface I
            transitions to the NoInfo state.  A PruneEcho(S,G) is sent
            onto the subnet connected to interface I.

            The action "Send PruneEcho(S,G)" is triggered when the
            router stops forwarding on an interface as a result of a
            prune.  A PruneEcho(S,G) is simply a Prune(S,G) message sent
            by the upstream router on a LAN with its own address in the
            Upstream Neighbor Address field.  Its purpose is to add
            additional reliability so that if a Prune that should have
            been overridden by another router is lost locally on the
            LAN, then the PruneEcho may be received and cause the
            override to happen.  A PruneEcho(S,G) need not be sent on an
            interface that contains only a single PIM neighbor during
            the time this state machine was in Prune-Pending state.








Fenner, et al.               Standards Track                   [Page 53]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.5.3.  Receiving (S,G,rpt) Join/Prune Messages

   The per-interface state machine for receiving (S,G,rpt) Join/Prune
   messages is given below.  There are five states:

      NoInfo (NI)
            The interface has no (S,G,rpt) Prune state and no (S,G,rpt)
            timers running.

      Prune (P)
            The interface has (S,G,rpt) Prune state, which will cause
            the router not to forward packets from S destined for G from
            this interface even though the interface has active (*,G)
            Join state.

      Prune-Pending (PP)
            The router has received a Prune(S,G,rpt) on this interface
            from a downstream neighbor and is waiting to see whether the
            prune will be overridden by another downstream router.  For
            forwarding purposes, the Prune-Pending state functions
            exactly like the NoInfo state.

      PruneTmp (P')
            This state is a transient state that for forwarding purposes
            behaves exactly like the Prune state.  A (*,G) Join has been
            received (which may cancel the (S,G,rpt) Prune).  As we
            parse the Join/Prune message from top to bottom, we first
            enter this state if the message contains a (*,G) Join.
            Later in the message, we will normally encounter an
            (S,G,rpt) prune to reinstate the Prune state.  However, if
            we reach the end of the message without encountering such an
            (S,G,rpt) prune, then we will revert to NoInfo state in this
            state machine.

            As no time is spent in this state, no timers can expire.

      Prune-Pending-Tmp (PP')
            This state is a transient state that is identical to P'
            except that it is associated with the PP state rather than
            the P state.  For forwarding purposes, PP' behaves exactly
            like the PP state.










Fenner, et al.               Standards Track                   [Page 54]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   In addition, there are two timers:

      Expiry Timer (ET)
            This timer is set when a valid Prune(S,G,rpt) is received.
            Expiry of the Expiry Timer causes this state machine to
            revert to NoInfo state.

      Prune-Pending Timer (PPT)
            This timer is set when a valid Prune(S,G,rpt) is received.
            Expiry of the Prune-Pending Timer causes this state machine
            to move on to Prune state.








































Fenner, et al.               Standards Track                   [Page 55]

RFC 7761             PIM-SM Specification (Revised)           March 2016


       Figure 4: Downstream Per-Interface (S,G,rpt) State Machine

+----------++----------------------------------------------------------+
|          ||                          Event                           |
|          ++---------+----------+----------+--------+--------+--------+
|Prev      ||Receive  | Receive  | Receive  | End of | Prune- | Expiry |
|State     ||Join(*,G)| Join     | Prune    | Message| Pending| Timer  |
|          ||         | (S,G,rpt)| (S,G,rpt)|        | Timer  | Expires|
|          ||         |          |          |        | Expires|        |
+----------++---------+----------+----------+--------+--------+--------+
|          ||-        | -        | -> PP    | -      | -      | -      |
|          ||         |          | state    |        |        |        |
|          ||         |          | start    |        |        |        |
|NoInfo    ||         |          | Prune-   |        |        |        |
|(NI)      ||         |          | Pending  |        |        |        |
|          ||         |          | Timer;   |        |        |        |
|          ||         |          | start    |        |        |        |
|          ||         |          | Expiry   |        |        |        |
|          ||         |          | Timer    |        |        |        |
+----------++---------+----------+----------+--------+--------+--------+
|          ||-> P'    | -> NI    | -> P     | -      | -      | -> NI  |
|          ||state    | state    | state    |        |        | state  |
|Prune (P) ||         |          | restart  |        |        |        |
|          ||         |          | Expiry   |        |        |        |
|          ||         |          | Timer    |        |        |        |
+----------++---------+----------+----------+--------+--------+--------+
|Prune-    ||-> PP'   | -> NI    | -        | -      | -> P   | -      |
|Pending   ||state    | state    |          |        | state  |        |
|(PP)      ||         |          |          |        |        |        |
+----------++---------+----------+----------+--------+--------+--------+
|          ||-        | -        | -> P     | -> NI  | -      | -      |
|PruneTmp  ||         |          | state    | state  |        |        |
|(P')      ||         |          | restart  |        |        |        |
|          ||         |          | Expiry   |        |        |        |
|          ||         |          | Timer    |        |        |        |
+----------++---------+----------+----------+--------+--------+--------+
|          ||-        | -        | -> PP    | -> NI  | -      | -      |
|Prune-    ||         |          | state    | state  |        |        |
|Pending-  ||         |          | restart  |        |        |        |
|Tmp (PP') ||         |          | Expiry   |        |        |        |
|          ||         |          | Timer    |        |        |        |
+----------++---------+----------+----------+--------+--------+--------+

   The transition events "Receive Join(S,G,rpt)", "Receive
   Prune(S,G,rpt)", and "Receive Join(*,G)" imply receiving a Join or
   Prune targeted to this router's primary IP address on the received
   interface.  If the upstream neighbor address field is not correct,




Fenner, et al.               Standards Track                   [Page 56]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   these state transitions in this state machine MUST NOT occur,
   although seeing such a packet may cause state transitions in other
   state machines.

   On unnumbered interfaces on point-to-point links, the router's
   address should be the same as the source address it chose for the
   Hello message it sent over that interface.  However, on point-to-
   point links it is RECOMMENDED that PIM Join/Prune messages with an
   upstream neighbor address field of all zeros also be accepted.

   Transitions from NoInfo State

   When in NoInfo (NI) state, the following event may trigger a
   transition:

      Receive Prune(S,G,rpt)
            A Prune(S,G,rpt) is received on interface I with its
            Upstream Neighbor Address set to the router's primary IP
            address on I.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the Prune-Pending state.  The Expiry Timer
            (ET) is started and set to the HoldTime from the triggering
            Join/Prune message.  The Prune-Pending Timer is started.  It
            is set to the J/P_Override_Interval(I) if the router has
            more than one neighbor on that interface; otherwise, it is
            set to zero, causing it to expire immediately.
























Fenner, et al.               Standards Track                   [Page 57]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from Prune-Pending State

   When in Prune-Pending (PP) state, the following events may trigger a
   transition:

      Receive Join(*,G)
            A Join(*,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the Prune-Pending-Tmp state whilst the
            remainder of the compound Join/Prune message containing the
            Join(*,G) is processed.

      Receive Join(S,G,rpt)
            A Join(S,G,rpt) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the NoInfo state.  The ET and PPT are
            canceled.

      Prune-Pending Timer Expires
            The Prune-Pending Timer for the (S,G,rpt) downstream state
            machine on interface I expires.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the Prune state.





















Fenner, et al.               Standards Track                   [Page 58]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from Prune State

   When in Prune (P) state, the following events may trigger a
   transition:

      Receive Join(*,G)
            A Join(*,G) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the PruneTmp state whilst the remainder of
            the compound Join/Prune message containing the Join(*,G) is
            processed.

      Receive Join(S,G,rpt)
            A Join(S,G,rpt) is received on interface I with its Upstream
            Neighbor Address set to the router's primary IP address
            on I.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the NoInfo state.  The ET and PPT are
            canceled.

      Receive Prune(S,G,rpt)
            A Prune(S,G,rpt) is received on interface I with its
            Upstream Neighbor Address set to the router's primary IP
            address on I.

            The (S,G,rpt) downstream state machine on interface I
            remains in Prune state.  The Expiry Timer (ET) is restarted
            and is then set to the maximum of its current value and the
            HoldTime from the triggering Join/Prune message.

      Expiry Timer Expires
            The Expiry Timer for the (S,G,rpt) downstream state machine
            on interface I expires.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the NoInfo state.











Fenner, et al.               Standards Track                   [Page 59]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from Prune-Pending-Tmp State

   When in Prune-Pending-Tmp (PP') state and processing a compound
   Join/Prune message, the following events may trigger a transition:

      Receive Prune(S,G,rpt)
            The compound Join/Prune message contains a Prune(S,G,rpt)
            that is received on interface I with its Upstream Neighbor
            Address set to the router's primary IP address on I.

            The (S,G,rpt) downstream state machine on interface I
            transitions back to the Prune-Pending state.  The
            Expiry Timer (ET) is restarted and is then set to the
            maximum of its current value and the HoldTime from the
            triggering Join/Prune message.

      End of Message
            The end of the compound Join/Prune message is reached.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the NoInfo state.  The ET and PPT are
            canceled.

   Transitions from PruneTmp State

   When in PruneTmp (P') state and processing a compound Join/Prune
   message, the following events may trigger a transition:

      Receive Prune(S,G,rpt)
            The compound Join/Prune message contains a Prune(S,G,rpt).

            The (S,G,rpt) downstream state machine on interface I
            transitions back to the Prune state.  The Expiry Timer (ET)
            is restarted and is then set to the maximum of its current
            value and the HoldTime from the triggering Join/Prune
            message.

      End of Message
            The end of the compound Join/Prune message is reached.

            The (S,G,rpt) downstream state machine on interface I
            transitions to the NoInfo state.  ET is canceled.

   Note: Receiving a Prune(*,G) does not affect the (S,G,rpt) downstream
   state machine.






Fenner, et al.               Standards Track                   [Page 60]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.5.4.  Sending (*,G) Join/Prune Messages

   The per-interface state machines for (*,G) hold join state from
   downstream PIM routers.  This state then determines whether a router
   needs to propagate a Join(*,G) upstream towards the RP.

   If a router wishes to propagate a Join(*,G) upstream, it must also
   watch for messages on its upstream interface from other routers on
   that subnet, and these may modify its behavior.  If it sees a
   Join(*,G) to the correct upstream neighbor, it should suppress its
   own Join(*,G).  If it sees a Prune(*,G) to the correct upstream
   neighbor, it should be prepared to override that prune by sending a
   Join(*,G) almost immediately.  Finally, if it sees the Generation ID
   (see Section 4.3) of the correct upstream neighbor change, it knows
   that the upstream neighbor has lost state, and it should be prepared
   to refresh the state by sending a Join(*,G) almost immediately.

   If a (*,G) Assert occurs on the upstream interface, and this changes
   this router's idea of the upstream neighbor, it should be prepared to
   ensure that the Assert winner is aware of downstream routers by
   sending a Join(*,G) almost immediately.

   In addition, if the MRIB changes to indicate that the next hop
   towards the RP has changed, and either the upstream interface changes
   or there is no Assert winner on the upstream interface, the router
   should prune off from the old next hop and join towards the new
   next hop.

   The upstream (*,G) state machine only contains two states:

      Not Joined
            The downstream state machines indicate that the router does
            not need to join the RP tree for this group.

      Joined
            The downstream state machines indicate that the router
            should join the RP tree for this group.

   In addition, one timer JT(*,G) is kept that is used to trigger the
   sending of a Join(*,G) to the upstream next hop towards the RP,
   RPF'(*,G).










Fenner, et al.               Standards Track                   [Page 61]

RFC 7761             PIM-SM Specification (Revised)           March 2016


                 Figure 5: Upstream (*,G) State Machine

+-------------------++-------------------------------------------------+
|                   ||                      Event                      |
|  Prev State       ++------------------------+------------------------+
|                   ||   JoinDesired(*,G)     |    JoinDesired(*,G)    |
|                   ||   ->True               |    ->False             |
+-------------------++------------------------+------------------------+
|                   ||   -> J state           |    -                   |
|  NotJoined (NJ)   ||   Send Join(*,G);      |                        |
|                   ||   set Join Timer to    |                        |
|                   ||   t_periodic           |                        |
+-------------------++------------------------+------------------------+
|  Joined (J)       ||   -                    |    -> NJ state         |
|                   ||                        |    Send Prune(*,G);    |
|                   ||                        |    cancel Join Timer   |
+-------------------++------------------------+------------------------+

   In addition, we have the following transitions, which occur within
   the Joined state:

+----------------------------------------------------------------------+
|                        In Joined (J) State                           |
+----------------+-----------------+-----------------+-----------------+
|Timer Expires   | See Join(*,G)   | See Prune(*,G)  | RPF'(*,G)       |
|                | to RPF'(*,G)    | to RPF'(*,G)    | changes due to  |
|                |                 |                 | an Assert       |
+----------------+-----------------+-----------------+-----------------+
|Send            | Increase Join   | Decrease Join   | Decrease Join   |
|Join(*,G); set  | Timer to        | Timer to        | Timer to        |
|Join Timer to   | t_joinsuppress  | t_override      | t_override      |
|t_periodic      |                 |                 |                 |
+----------------+-----------------+-----------------+-----------------+

+----------------------------------------------------------------------+
|                         In Joined (J) State                          |
+----------------------------------+-----------------------------------+
|    RPF'(*,G) changes not         |       RPF'(*,G) GenID changes     |
|    due to an Assert              |                                   |
+----------------------------------+-----------------------------------+
|    Send Join(*,G) to new         |       Decrease Join Timer to      |
|    next hop; send                |       t_override                  |
|    Prune(*,G) to old next        |                                   |
|    hop; set Join Timer to        |                                   |
|    t_periodic                    |                                   |
+----------------------------------+-----------------------------------+





Fenner, et al.               Standards Track                   [Page 62]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   This state machine uses the following macro:

     bool JoinDesired(*,G) {
        if (immediate_olist(*,G) != NULL)
            return TRUE
        else
            return FALSE
     }

   JoinDesired(*,G) is true when the router has forwarding state that
   would cause it to forward traffic for G using shared tree state.
   Note that although JoinDesired is true, the router's sending of a
   Join(*,G) message may be suppressed by another router sending a
   Join(*,G) onto the upstream interface.

   Transitions from NotJoined State

   When the upstream (*,G) state machine is in NotJoined state, the
   following event may trigger a state transition:

      JoinDesired(*,G) becomes True
            The macro JoinDesired(*,G) becomes True, e.g., because the
            downstream state for (*,G) has changed so that at least one
            interface is in immediate_olist(*,G).

            The upstream (*,G) state machine transitions to the Joined
            state.  Send Join(*,G) to the appropriate upstream neighbor,
            which is RPF'(*,G).  Set the Join Timer (JT) to expire after
            t_periodic seconds.

   Transitions from Joined State

   When the upstream (*,G) state machine is in Joined state, the
   following events may trigger state transitions:

      JoinDesired(*,G) becomes False
            The macro JoinDesired(*,G) becomes False, e.g., because the
            downstream state for (*,G) has changed so no interface is in
            immediate_olist(*,G).

            The upstream (*,G) state machine transitions to the
            NotJoined state.  Send Prune(*,G) to the appropriate
            upstream neighbor, which is RPF'(*,G).  Cancel the
            Join Timer (JT).







Fenner, et al.               Standards Track                   [Page 63]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      Join Timer Expires
            The Join Timer (JT) expires, indicating time to send a
            Join(*,G).

            Send Join(*,G) to the appropriate upstream neighbor, which
            is RPF'(*,G).  Restart the Join Timer (JT) to expire after
            t_periodic seconds.

      See Join(*,G) to RPF'(*,G)
            This event is only relevant if RPF_interface(RP(G)) is a
            shared medium.  This router sees another router on
            RPF_interface(RP(G)) send a Join(*,G) to RPF'(*,G).  This
            causes this router to suppress its own Join.

            The upstream (*,G) state machine remains in Joined state.

            Let t_joinsuppress be the minimum of t_suppressed and the
            HoldTime from the Join/Prune message triggering this event.
            If the Join Timer is set to expire in less than
            t_joinsuppress seconds, reset it so that it expires after
            t_joinsuppress seconds.  If the Join Timer is set to expire
            in more than t_joinsuppress seconds, leave it unchanged.

      See Prune(*,G) to RPF'(*,G)
            This event is only relevant if RPF_interface(RP(G)) is a
            shared medium.  This router sees another router on
            RPF_interface(RP(G)) send a Prune(*,G) to RPF'(*,G).  As
            this router is in Joined state, it must override the Prune
            after a short random interval.

            The upstream (*,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.  If the Join Timer is set to expire in
            less than t_override seconds, leave it unchanged.

      RPF'(*,G) changes due to an Assert
            The current next hop towards the RP changes due to an
            Assert(*,G) on the RPF_interface(RP(G)).

            The upstream (*,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.  If the Join Timer is set to expire in
            less than t_override seconds, leave it unchanged.






Fenner, et al.               Standards Track                   [Page 64]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      RPF'(*,G) changes not due to an Assert
            An event occurred that caused the next hop towards the RP
            for G to change.  This may be caused by a change in the MRIB
            routing database or the group-to-RP mapping.  Note that this
            transition does not occur if an Assert is active and the
            upstream interface does not change.

            The upstream (*,G) state machine remains in Joined state.
            Send Join(*,G) to the new upstream neighbor, which is the
            new value of RPF'(*,G).  Send Prune(*,G) to the old upstream
            neighbor, which is the old value of RPF'(*,G).  Use the new
            value of RP(G) in the Prune(*,G) message or all zeros if
            RP(G) becomes unknown (old value of RP(G) may be used
            instead to improve behavior in routers implementing older
            versions of this specification).  Set the Join Timer (JT) to
            expire after t_periodic seconds.

      RPF'(*,G) GenID changes
            The Generation ID of the router that is RPF'(*,G) changes.
            This normally means that this neighbor has lost state, and
            so the state must be refreshed.

            The upstream (*,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.

4.5.5.  Sending (S,G) Join/Prune Messages

   The per-interface state machines for (S,G) hold join state from
   downstream PIM routers.  This state then determines whether a router
   needs to propagate a Join(S,G) upstream towards the source.

   If a router wishes to propagate a Join(S,G) upstream, it must also
   watch for messages on its upstream interface from other routers on
   that subnet, and these may modify its behavior.  If it sees a
   Join(S,G) to the correct upstream neighbor, it should suppress its
   own Join(S,G).  If it sees a Prune(S,G), Prune(S,G,rpt), or
   Prune(*,G) to the correct upstream neighbor towards S, it should be
   prepared to override that prune by scheduling a Join(S,G) to be sent
   almost immediately.  Finally, if it sees the Generation ID of its
   upstream neighbor change, it knows that the upstream neighbor has
   lost state, and it should refresh the state by scheduling a Join(S,G)
   to be sent almost immediately.







Fenner, et al.               Standards Track                   [Page 65]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   If an (S,G) Assert occurs on the upstream interface, and this changes
   this router's idea of the upstream neighbor, it should be prepared to
   ensure that the Assert winner is aware of downstream routers by
   scheduling a Join(S,G) to be sent almost immediately.

   In addition, if MRIB changes cause the next hop towards the source to
   change, and either the upstream interface changes or there is no
   Assert winner on the upstream interface, the router should send a
   prune to the old next hop and a join to the new next hop.

   The upstream (S,G) state machine only contains two states:

      Not Joined
            The downstream state machines and local membership
            information do not indicate that the router needs to join
            the shortest-path tree for this (S,G).

      Joined
            The downstream state machines and local membership
            information indicate that the router should join the
            shortest-path tree for this (S,G).

   In addition, one timer JT(S,G) is kept that is used to trigger the
   sending of a Join(S,G) to the upstream next hop towards S, RPF'(S,G).

                 Figure 6: Upstream (S,G) State Machine

+-------------------+--------------------------------------------------+
|                   |                      Event                       |
|  Prev State       +-------------------------+------------------------+
|                   |   JoinDesired(S,G)      |   JoinDesired(S,G)     |
|                   |   ->True                |   ->False              |
+-------------------+-------------------------+------------------------+
|  NotJoined (NJ)   |   -> J state            |   -                    |
|                   |   Send Join(S,G);       |                        |
|                   |   set Join Timer to     |                        |
|                   |   t_periodic            |                        |
+-------------------+-------------------------+------------------------+
|  Joined (J)       |   -                     |   -> NJ state          |
|                   |                         |   Send Prune(S,G);     |
|                   |                         |   set SPTbit(S,G) to   |
|                   |                         |   FALSE; cancel Join   |
|                   |                         |   Timer                |
+-------------------+-------------------------+------------------------+







Fenner, et al.               Standards Track                   [Page 66]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   In addition, we have the following transitions, which occur within
   the Joined state:

+----------------------------------------------------------------------+
|                         In Joined (J) State                          |
+-----------------+-----------------+-----------------+----------------+
| Timer Expires   | See Join(S,G)   | See Prune(S,G)  | See Prune      |
|                 | to RPF'(S,G)    | to RPF'(S,G)    | (S,G,rpt) to   |
|                 |                 |                 | RPF'(S,G)      |
+-----------------+-----------------+-----------------+----------------+
| Send            | Increase Join   | Decrease Join   | Decrease Join  |
| Join(S,G); set  | Timer to        | Timer to        | Timer to       |
| Join Timer to   | t_joinsuppress  | t_override      | t_override     |
| t_periodic      |                 |                 |                |
+-----------------+-----------------+-----------------+----------------+

+----------------------------------------------------------------------+
|                        In Joined (J) State                           |
+-----------------+-----------------+----------------+-----------------+
| See Prune(*,G)  | RPF'(S,G)       | RPF'(S,G)      | RPF'(S,G)       |
| to RPF'(S,G)    | changes not     | GenID changes  | changes due to  |
|                 | due to an       |                | an Assert       |
|                 | Assert          |                |                 |
+-----------------+-----------------+----------------+-----------------+
| Decrease Join   | Send Join(S,G)  | Decrease Join  | Decrease Join   |
| Timer to        | to new next     | Timer to       | Timer to        |
| t_override      | hop; send       | t_override     | t_override      |
|                 | Prune(S,G) to   |                |                 |
|                 | old next hop;   |                |                 |
|                 | set Join Timer  |                |                 |
|                 | to t_periodic   |                |                 |
+-----------------+-----------------+----------------+-----------------+

   This state machine uses the following macro:

     bool JoinDesired(S,G) {
         return( immediate_olist(S,G) != NULL
                 OR ( KeepaliveTimer(S,G) is running
                      AND inherited_olist(S,G) != NULL ) )
     }

   JoinDesired(S,G) is true when the router has forwarding state that
   would cause it to forward traffic for G using source tree state.  The
   source tree state can be as a result of either active source-specific
   join state, or the (S,G) Keepalive Timer and active non-source-
   specific state.  Note that although JoinDesired is true, the router's
   sending of a Join(S,G) message may be suppressed by another router
   sending a Join(S,G) onto the upstream interface.



Fenner, et al.               Standards Track                   [Page 67]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from NotJoined State

   When the upstream (S,G) state machine is in NotJoined state, the
   following event may trigger a state transition:

      JoinDesired(S,G) becomes True
            The macro JoinDesired(S,G) becomes True, e.g., because the
            downstream state for (S,G) has changed so that at least one
            interface is in inherited_olist(S,G).

            The upstream (S,G) state machine transitions to the Joined
            state.  Send Join(S,G) to the appropriate upstream neighbor,
            which is RPF'(S,G).  Set the Join Timer (JT) to expire after
            t_periodic seconds.

   Transitions from Joined State

   When the upstream (S,G) state machine is in Joined state, the
   following events may trigger state transitions:

      JoinDesired(S,G) becomes False
            The macro JoinDesired(S,G) becomes False, e.g., because the
            downstream state for (S,G) has changed so no interface is in
            inherited_olist(S,G).

            The upstream (S,G) state machine transitions to the
            NotJoined state.  Send Prune(S,G) to the appropriate
            upstream neighbor, which is RPF'(S,G).  Cancel the
            Join Timer (JT), and set SPTbit(S,G) to FALSE.

      Join Timer Expires
            The Join Timer (JT) expires, indicating time to send a
            Join(S,G).

            Send Join(S,G) to the appropriate upstream neighbor, which
            is RPF'(S,G).  Restart the Join Timer (JT) to expire after
            t_periodic seconds.














Fenner, et al.               Standards Track                   [Page 68]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      See Join(S,G) to RPF'(S,G)
            This event is only relevant if RPF_interface(S) is a shared
            medium.  This router sees another router on RPF_interface(S)
            send a Join(S,G) to RPF'(S,G).  This causes this router to
            suppress its own Join.

            The upstream (S,G) state machine remains in Joined state.

            Let t_joinsuppress be the minimum of t_suppressed and the
            HoldTime from the Join/Prune message triggering this event.

            If the Join Timer is set to expire in less than
            t_joinsuppress seconds, reset it so that it expires after
            t_joinsuppress seconds.  If the Join Timer is set to expire
            in more than t_joinsuppress seconds, leave it unchanged.

      See Prune(S,G) to RPF'(S,G)
            This event is only relevant if RPF_interface(S) is a shared
            medium.  This router sees another router on RPF_interface(S)
            send a Prune(S,G) to RPF'(S,G).  As this router is in Joined
            state, it must override the Prune after a short random
            interval.

            The upstream (S,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.

      See Prune(S,G,rpt) to RPF'(S,G)
            This event is only relevant if RPF_interface(S) is a shared
            medium.  This router sees another router on RPF_interface(S)
            send a Prune(S,G,rpt) to RPF'(S,G).  If the upstream router
            is an RFC-2362-compliant PIM router, then the Prune(S,G,rpt)
            will cause it to stop forwarding.  For backwards
            compatibility, this router should override the prune so that
            forwarding continues.

            The upstream (S,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.










Fenner, et al.               Standards Track                   [Page 69]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      See Prune(*,G) to RPF'(S,G)
            This event is only relevant if RPF_interface(S) is a shared
            medium.  This router sees another router on RPF_interface(S)
            send a Prune(*,G) to RPF'(S,G).  If the upstream router is
            an RFC-2362-compliant PIM router, then the Prune(*,G) will
            cause it to stop forwarding.  For backwards compatibility,
            this router should override the prune so that forwarding
            continues.

            The upstream (S,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.

      RPF'(S,G) changes due to an Assert
            The current next hop towards S changes due to an Assert(S,G)
            on the RPF_interface(S).

            The upstream (S,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.  If the Join Timer is set to expire in
            less than t_override seconds, leave it unchanged.

      RPF'(S,G) changes not due to an Assert
            An event occurred that caused the next hop towards S to
            change.  Note that this transition does not occur if an
            Assert is active and the upstream interface does not change.

            The upstream (S,G) state machine remains in Joined state.
            Send Join(S,G) to the new upstream neighbor, which is the
            new value of RPF'(S,G).  Send Prune(S,G) to the old upstream
            neighbor, which is the old value of RPF'(S,G).  Set the
            Join Timer (JT) to expire after t_periodic seconds.

      RPF'(S,G) GenID changes
            The Generation ID of the router that is RPF'(S,G) changes.
            This normally means that this neighbor has lost state, and
            so the state must be refreshed.

            The upstream (S,G) state machine remains in Joined state.
            If the Join Timer is set to expire in more than
            t_override seconds, reset it so that it expires after
            t_override seconds.







Fenner, et al.               Standards Track                   [Page 70]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.5.6.  (S,G,rpt) Periodic Messages

   (S,G,rpt) Joins and Prunes are (S,G) Joins or Prunes sent on the RP
   tree with the RPT bit set, either to modify the results of (*,G)
   Joins, or to override the behavior of other upstream LAN peers.  The
   next section describes the rules for sending triggered messages.
   This section describes the rules for including a Prune(S,G,rpt)
   message with a Join(*,G).

   When a router is going to send a Join(*,G), it should use the
   following pseudocode, for each (S,G) for which it has state, to
   decide whether to include a Prune(S,G,rpt) in the compound Join/Prune
   message:

     if( SPTbit(S,G) == TRUE ) {
         # Note: If receiving (S,G) on the SPT, we only prune off the
         # shared tree if the RPF neighbors differ.
          if( RPF'(*,G) != RPF'(S,G) ) {
              add Prune(S,G,rpt) to compound message
          }
     } else if ( inherited_olist(S,G,rpt) == NULL ) {
       # Note: All (*,G) olist interfaces received RPT prunes for (S,G).
       add Prune(S,G,rpt) to compound message
     } else if ( RPF'(*,G) != RPF'(S,G,rpt) {
       # Note: We joined the shared tree, but there was an (S,G) assert
       # and the source tree RPF neighbor is different.
       add Prune(S,G,rpt) to compound message
     }

   Note that Join(S,G,rpt) is normally sent not as a periodic message,
   but only as a triggered message.




















Fenner, et al.               Standards Track                   [Page 71]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.5.7.  State Machine for (S,G,rpt) Triggered Messages

   The state machine for (S,G,rpt) triggered messages is required
   per-(S,G) when there is (*,G) join state at a router, and the router
   or any of its upstream LAN peers wishes to prune S off the RP tree.

   There are three states in the state machine.  One of the states is
   when there is no (*,G) join state at this router.  If there is (*,G)
   join state at the router, then the state machine must be at one of
   the other two states.  The three states are:

      Pruned(S,G,rpt)
         (*,G) Joined, but (S,G,rpt) pruned.

      NotPruned(S,G,rpt)
         (*,G) Joined, and (S,G,rpt) not pruned.

      RPTNotJoined(G)
         (*,G) has not been joined.

   In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt), which
   is used to delay triggered Join(S,G,rpt) messages to prevent
   implosions of triggered messages.

   Figure 7: Upstream (S,G,rpt) State Machine for Triggered Messages

+------------++--------------------------------------------------------+
|            ||                           Event                        |
|            ++--------------+--------------+-------------+------------+
|Prev State  || PruneDesired | PruneDesired | RPTJoin     | inherited_ |
|            || (S,G,rpt)    | (S,G,rpt)    | Desired(G)  | olist      |
|            || ->True       | ->False      | ->False     | (S,G,rpt)  |
|            ||              |              |             | ->non-NULL |
+------------++--------------+--------------+-------------+------------+
|RPTNotJoined|| -> P state   | -            | -           | -> NP state|
|(G) (NJ)    ||              |              |             |            |
+------------++--------------+--------------+-------------+------------+
|Pruned      || -            | -> NP state  | -> NJ state | -          |
|(S,G,rpt)   ||              | Send Join    |             |            |
|(P)         ||              | (S,G,rpt)    |             |            |
+------------++--------------+--------------+-------------+------------+
|NotPruned   || -> P state   | -            | -> NJ state | -          |
|(S,G,rpt)   || Send Prune   |              | Cancel OT   |            |
|(NP)        || (S,G,rpt);   |              |             |            |
|            || cancel OT    |              |             |            |
+------------++--------------+--------------+-------------+------------+





Fenner, et al.               Standards Track                   [Page 72]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Additionally, we have the following transitions within the
   NotPruned(S,G,rpt) state, which are all used for prune override
   behavior.

+----------------------------------------------------------------------+
|                    In NotPruned(S,G,rpt) State                       |
+----------+--------------+--------------+--------------+--------------+
|Override  | See Prune    | See Join     | See Prune    | RPF'         |
|Timer     | (S,G,rpt) to | (S,G,rpt) to | (S,G) to     | (S,G,rpt) -> |
|expires   | RPF'         | RPF'         | RPF'         | RPF' (*,G)   |
|          | (S,G,rpt)    | (S,G,rpt)    | (S,G,rpt)    |              |
+----------+--------------+--------------+--------------+--------------+
|Send Join | OT = min(OT, | Cancel OT    | OT = min(OT, | OT = min(OT, |
|(S,G,rpt);| t_override)  |              | t_override)  | t_override)  |
|leave OT  |              |              |              |              |
|unset     |              |              |              |              |
+----------+--------------+--------------+--------------+--------------+

   Note that the min function in the above state machine considers a
   non-running timer to have an infinite value (e.g., min(not-running,
   t_override) = t_override).

   This state machine uses the following macros:

     bool RPTJoinDesired(G) {
       return (JoinDesired(*,G))
     }

   RPTJoinDesired(G) is true when the router has forwarding state that
   would cause it to forward traffic for G using (*,G) shared tree
   state.

     bool PruneDesired(S,G,rpt) {
          return ( RPTJoinDesired(G) AND
                   ( inherited_olist(S,G,rpt) == NULL
                     OR (SPTbit(S,G)==TRUE
                         AND (RPF'(*,G) != RPF'(S,G)) )))
     }

   PruneDesired(S,G,rpt) can only be true if RPTJoinDesired(G) is true.
   If RPTJoinDesired(G) is true, then PruneDesired(S,G,rpt) is true
   either if there are no outgoing interfaces that S would be forwarded
   on, or if the router has active (S,G) forwarding state but RPF'(*,G)
   != RPF'(S,G).







Fenner, et al.               Standards Track                   [Page 73]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The state machine contains the following transition events:

      See Join(S,G,rpt) to RPF'(S,G,rpt)
            This event is only relevant in the "Not Pruned" state.

            The router sees a Join(S,G,rpt) from someone else to
            RPF'(S,G,rpt), which is the correct upstream neighbor.  If
            we're in "NotPruned" state and the (S,G,rpt) Override Timer
            is running, then this is because we have been triggered to
            send our own Join(S,G,rpt) to RPF'(S,G,rpt).  Someone else
            beat us to it, so there's no need to send our own Join.

            The action is to cancel the Override Timer.

      See Prune(S,G,rpt) to RPF'(S,G,rpt)
            This event is only relevant in the "NotPruned" state.

            The router sees a Prune(S,G,rpt) from someone else to
            RPF'(S,G,rpt), which is the correct upstream neighbor.  If
            we're in the "NotPruned" state, then we want to continue to
            receive traffic from S destined for G, and that traffic is
            being supplied by RPF'(S,G,rpt).  Thus, we need to override
            the Prune.

            The action is to set the (S,G,rpt) Override Timer to the
            randomized prune-override interval, t_override.  However, if
            the Override Timer is already running, we only set the timer
            if doing so would set it to a lower value.  At the end of
            this interval, if no one else has sent a Join, then we will
            do so.

      See Prune(S,G) to RPF'(S,G,rpt)
            This event is only relevant in the "NotPruned" state.

            This transition and action are the same as the above
            transition and action, except that the Prune does not have
            the RPT bit set.  This transition is necessary to be
            compatible with routers implemented from RFC 2362 that don't
            maintain separate (S,G) and (S,G,rpt) state.












Fenner, et al.               Standards Track                   [Page 74]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      The (S,G,rpt) prune Override Timer expires
            This event is only relevant in the "NotPruned" state.

            When the Override Timer expires, we must send a
            Join(S,G,rpt) to RPF'(S,G,rpt) to override the Prune message
            that caused the timer to be running.  We only send this if
            RPF'(S,G,rpt) equals RPF'(*,G); if this were not the case,
            then the Join might be sent to a router that does not have
            (*,G) Join state, and so the behavior would not be well
            defined.  If RPF'(S,G,rpt) is not the same as RPF'(*,G),
            then it may stop forwarding S.  However, if this happens,
            then the router will send an AssertCancel(S,G), which would
            then cause RPF'(S,G,rpt) to become equal to RPF'(*,G) (see
            below).

      RPF'(S,G,rpt) changes to become equal to RPF'(*,G)
            This event is only relevant in the "NotPruned" state.

            RPF'(S,G,rpt) can only be different from RPF'(*,G) if an
            (S,G) Assert has happened, which means that traffic from S
            is arriving on the SPT, and so Prune(S,G,rpt) will have been
            sent to RPF'(*,G).  When RPF'(S,G,rpt) changes to become
            equal to RPF'(*,G), we need to trigger a Join(S,G,rpt) to
            RPF'(*,G) to cause that router to start forwarding S again.

            The action is to set the (S,G,rpt) Override Timer to the
            randomized prune-override interval t_override.  However, if
            the timer is already running, we only set the timer if doing
            so would set it to a lower value.  At the end of this
            interval, if no one else has sent a Join, then we will
            do so.

      PruneDesired(S,G,rpt)->TRUE
            See macro above.  This event is relevant in the "NotPruned"
            and "RPTNotJoined(G)" states.

            The router wishes to receive traffic for G but does not wish
            to receive traffic from S destined for G.  This causes the
            router to transition into the Pruned state.

            If the router was previously in NotPruned state, then the
            action is to send a Prune(S,G,rpt) to RPF'(S,G,rpt), and to
            cancel the Override Timer.  If the router was previously in
            RPTNotJoined(G) state, then there is no need to trigger an
            action in this state machine because sending a
            Prune(S,G,rpt) is handled by the rules for sending the
            Join(*,G).




Fenner, et al.               Standards Track                   [Page 75]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      PruneDesired(S,G,rpt)->FALSE
            See macro above.  This transition is only relevant in the
            "Pruned" state.

            If the router is in the Pruned(S,G,rpt) state, and
            PruneDesired(S,G,rpt) changes to FALSE, this could be
            because the router no longer has RPTJoinDesired(G) true, or
            it now wishes to receive traffic from S again.  If it is the
            former, then this transition should not happen, but instead
            the "RPTJoinDesired(G)->FALSE" transition should happen.
            Thus, this transition should be interpreted as
            "PruneDesired(S,G,rpt)->FALSE AND RPTJoinDesired(G)==TRUE".

            The action is to send a Join(S,G,rpt) to RPF'(S,G,rpt).

      RPTJoinDesired(G)->FALSE
            This event is relevant in the "Pruned" and "NotPruned"
            states.

            The router no longer wishes to receive any traffic destined
            for G on the RP Tree.  This causes a transition to the
            RPTNotJoined(G) state, and the Override Timer is canceled if
            it was running.  Any further actions are handled by the
            appropriate upstream state machine for (*,G).

      inherited_olist(S,G,rpt) becomes non-NULL
            This transition is only relevant in the RPTNotJoined(G)
            state.

            The router has joined the RP tree (handled by the (*,G)
            upstream state machine as appropriate) and wants to receive
            traffic from S.  This does not trigger any events in this
            state machine, but causes a transition to the
            NotPruned(S,G,rpt) state.

4.6.  PIM Assert Messages

   Where multiple PIM routers peer over a shared LAN, it is possible for
   more than one upstream router to have valid forwarding state for a
   packet, which can lead to packet duplication (see Section 3.6).  PIM
   does not attempt to prevent this from occurring.  Instead, it detects
   when this has happened and elects a single forwarder amongst the
   upstream routers to prevent further duplication.  This election is
   performed using PIM Assert messages.  Assert messages are also
   received by downstream routers on the LAN, and these cause subsequent
   Join/Prune messages to be sent to the upstream router that won the
   Assert.




Fenner, et al.               Standards Track                   [Page 76]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   In general, a PIM Assert message should only be accepted for
   processing if it comes from a known PIM neighbor.  A PIM router hears
   about PIM neighbors through PIM Hello messages.  If a router receives
   an Assert message from a particular IP source address and it has not
   seen a PIM Hello message from that source address, then the Assert
   message SHOULD be discarded without further processing.  In addition,
   if the Hello message from a neighbor was authenticated (see
   Section 6.3), then all Assert messages from that neighbor MUST also
   be authenticated.

   We note that some older PIM implementations incorrectly fail to send
   Hello messages on point-to-point interfaces, so we also RECOMMEND
   that a configuration option be provided to allow interoperation with
   such older routers, but that this configuration option SHOULD NOT be
   enabled by default.

4.6.1.  (S,G) Assert Message State Machine

   The (S,G) Assert state machine for interface I is shown in Figure 8.
   There are three states:

      NoInfo (NI)
            This router has no (S,G) assert state on interface I.

      I am Assert Winner (W)
            This router has won an (S,G) assert on interface I.  It is
            now responsible for forwarding traffic from S destined for G
            out of interface I.  Irrespective of whether it is the DR
            for I, while a router is the assert winner, it is also
            responsible for forwarding traffic onto I on behalf of local
            hosts on I that have made membership requests that
            specifically refer to S (and G).

      I am Assert Loser (L)
            This router has lost an (S,G) assert on interface I.  It
            must not forward packets from S destined for G onto
            interface I.  If it is the DR on I, it is no longer
            responsible for forwarding traffic onto I to satisfy local
            hosts with membership requests that specifically refer to S
            and G.

   In addition, there is also an Assert Timer (AT) that is used to
   time out asserts on the assert losers and to resend asserts on the
   assert winner.







Fenner, et al.               Standards Track                   [Page 77]

RFC 7761             PIM-SM Specification (Revised)           March 2016


           Figure 8: Per-Interface (S,G) Assert State Machine

+----------------------------------------------------------------------+
|                         In NoInfo (NI) State                         |
+---------------+-------------------+------------------+---------------+
| Receive       |  Receive Assert   |  Data arrives    |  Receive      |
| Inferior      |  with RPTbit      |  from S to G on  |  Acceptable   |
| Assert with   |  set and          |  I and           |  Assert with  |
| RPTbit clear  |  CouldAssert      |  CouldAssert     |  RPTbit clear |
|               |  (S,G,I)          |  (S,G,I)         |  and AssTrDes |
|               |                   |                  |  (S,G,I)      |
+---------------+-------------------+------------------+---------------+
| -> W state    |  -> W state       |  -> W state      |  -> L state   |
| [Actions A1]  |  [Actions A1]     |  [Actions A1]    |  [Actions A6] |
+---------------+-------------------+------------------+---------------+

+----------------------------------------------------------------------+
|                   In I Am Assert Winner (W) State                    |
+----------------+------------------+-----------------+----------------+
| Assert Timer   |   Receive        |  Receive        |  CouldAssert   |
| Expires        |   Inferior       |  Preferred      |  (S,G,I) ->    |
|                |   Assert         |  Assert         |  FALSE         |
+----------------+------------------+-----------------+----------------+
| -> W state     |   -> W state     |  -> L state     |  -> NI state   |
| [Actions A3]   |   [Actions A3]   |  [Actions A2]   |  [Actions A4]  |
+----------------+------------------+-----------------+----------------+

+---------------------------------------------------------------------+
|                   In I Am Assert Loser (L) State                    |
+-------------+-------------+-------------+-------------+-------------+
|Receive      |Receive      |Receive      |Assert Timer |Current      |
|Preferred    |Acceptable   |Inferior     |Expires      |Winner's     |
|Assert       |Assert with  |Assert or    |             |GenID        |
|             |RPTbit clear |Assert       |             |Changes or   |
|             |from Current |Cancel from  |             |NLT Expires  |
|             |Winner       |Current      |             |             |
|             |             |Winner       |             |             |
+-------------+-------------+-------------+-------------+-------------+
|-> L state   |-> L state   |-> NI state  |-> NI state  |-> NI state  |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------+










Fenner, et al.               Standards Track                   [Page 78]

RFC 7761             PIM-SM Specification (Revised)           March 2016


+----------------------------------------------------------------------+
|                    In I Am Assert Loser (L) State                    |
+----------------+-----------------+------------------+----------------+
| AssTrDes       |  my_metric ->   |  RPF_interface   |  Receive       |
| (S,G,I) ->     |  better than    |  (S) stops       |  Join(S,G) on  |
| FALSE          |  winner's       |  being I         |  interface I   |
|                |  metric         |                  |                |
+----------------+-----------------+------------------+----------------+
| -> NI state    |  -> NI state    |  -> NI state     |  -> NI State   |
| [Actions A5]   |  [Actions A5]   |  [Actions A5]    |  [Actions A5]  |
+----------------+-----------------+------------------+----------------+

   Note that for reasons of compactness, "AssTrDes(S,G,I)" is used in
   the state machine table to refer to AssertTrackingDesired(S,G,I).

   Terminology:

      A "preferred assert" is one with a better metric than the current
      winner.

      An "acceptable assert" is one that has a better metric than
      my_assert_metric(S,G,I).  An assert is never considered acceptable
      if its metric is infinite.

      An "inferior assert" is one with a worse metric than
      my_assert_metric(S,G,I).  An assert is never considered inferior
      if my_assert_metric(S,G,I) is infinite.

   The state machine uses the following macros:

   CouldAssert(S,G,I) =
        SPTbit(S,G)==TRUE
        AND (RPF_interface(S) != I)
        AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) )
                    (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
                    (-) lost_assert(*,G)
                    (+) joins(S,G) (+) pim_include(S,G) ) )

   CouldAssert(S,G,I) is true for downstream interfaces that would be in
   the inherited_olist(S,G) if (S,G) assert information was not taken
   into account.










Fenner, et al.               Standards Track                   [Page 79]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   AssertTrackingDesired(S,G,I) =
        (I in ( joins(*,G) (-) prunes(S,G,rpt)
                (+) ( pim_include(*,G) (-) pim_exclude(S,G) )
                (-) lost_assert(*,G)
                (+) joins(S,G) ) )
        OR (local_receiver_include(S,G,I) == TRUE
            AND (I_am_DR(I) OR (AssertWinner(S,G,I) == me)))
        OR ((RPF_interface(S) == I) AND (JoinDesired(S,G) == TRUE))
        OR ((RPF_interface(RP(G)) == I) AND (JoinDesired(*,G) == TRUE)
            AND (SPTbit(S,G) == FALSE))

   AssertTrackingDesired(S,G,I) is true on any interface in which an
   (S,G) assert might affect the router's behavior on that interface.

   The first three lines of AssertTrackingDesired account for (*,G) join
   and local membership information received on I that might cause the
   router to be interested in asserts on I.

   The 4th line accounts for (S,G) join information received on I that
   might cause the router to be interested in asserts on I.

   The 5th and 6th lines account for (S,G) local membership information
   on I.  Note that we can't use the pim_include(S,G) macro, since it
   uses lost_assert(S,G,I) and would result in the router forgetting
   that it lost an assert if the only reason it was interested was local
   membership.  The AssertWinner(S,G,I) check forces an assert winner to
   keep on being responsible for forwarding as long as local receivers
   are present.  Removing this check would make the assert winner
   give up forwarding as soon as the information that originally caused
   it to forward went away, and the task of forwarding for local
   receivers would revert back to the DR.

   The last three lines account for the fact that a router must keep
   track of assert information on upstream interfaces in order to send
   joins and prunes to the proper neighbor.
















Fenner, et al.               Standards Track                   [Page 80]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from NoInfo State

   When in NoInfo state, the following events may trigger transitions:

      Receive Inferior Assert with RPTbit cleared
            An assert is received for (S,G) with the RPT bit cleared
            that is inferior to our own assert metric.  The RPT bit
            cleared indicates that the sender of the assert had (S,G)
            forwarding state on this interface.  If the assert is
            inferior to our metric, then we must also have (S,G)
            forwarding state (i.e., CouldAssert(S,G,I)==TRUE) as (S,G)
            asserts have priority over (*,G) asserts, and so we should
            be the assert winner.  We transition to the "I am Assert
            Winner" state and perform Actions A1 (below).

      Receive Assert with RPTbit set AND CouldAssert(S,G,I)==TRUE
            An assert is received for (S,G) on I with the RPT bit set
            (it is a (*,G) assert).  CouldAssert(S,G,I) is TRUE only if
            we have (S,G) forwarding state on this interface, so we
            should be the assert winner.  We transition to the "I am
            Assert Winner" state and perform Actions A1 (below).

      An (S,G) data packet arrives on interface I, AND
         CouldAssert(S,G,I)==TRUE
            An (S,G) data packet arrived on a downstream interface that
            is in our (S,G) outgoing interface list.  We optimistically
            assume that we will be the assert winner for this (S,G), and
            so we transition to the "I am Assert Winner" state and
            perform Actions A1 (below), which will initiate the assert
            negotiation for (S,G).

      Receive Acceptable Assert with RPT bit clear AND
         AssertTrackingDesired(S,G,I)==TRUE
            We're interested in (S,G) Asserts, either because I is a
            downstream interface for which we have (S,G) or (*,G)
            forwarding state, or because I is the upstream interface for
            S and we have (S,G) forwarding state.  The received assert
            has a better metric than our own, so we do not win the
            Assert.  We transition to "I am Assert Loser" and perform
            Actions A6 (below).











Fenner, et al.               Standards Track                   [Page 81]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from "I am Assert Winner" State

   When in "I am Assert Winner" state, the following events trigger
   transitions:

      Assert Timer Expires
            The (S,G) Assert Timer expires.  As we're in the Winner
            state, we must still have (S,G) forwarding state that is
            actively being kept alive.  We resend the (S,G) Assert and
            restart the Assert Timer (Actions A3 below).  Note that the
            assert winner's Assert Timer is engineered to expire shortly
            before timers on assert losers; this prevents unnecessary
            thrashing of the forwarder and periodic flooding of
            duplicate packets.

      Receive Inferior Assert
            We receive an (S,G) assert or (*,G) assert mentioning S that
            has a worse metric than our own.  Whoever sent the assert is
            in error, and so we resend an (S,G) Assert and restart the
            Assert Timer (Actions A3 below).

      Receive Preferred Assert
            We receive an (S,G) assert that has a better metric than our
            own.  We transition to "I am Assert Loser" state and perform
            Actions A2 (below).  Note that this may affect the value of
            JoinDesired(S,G) and PruneDesired(S,G,rpt), which could
            cause transitions in the upstream (S,G) or (S,G,rpt) state
            machines.

      CouldAssert(S,G,I) -> FALSE
            Our (S,G) forwarding state or RPF interface changed so as to
            make CouldAssert(S,G,I) become false.  We can no longer
            perform the actions of the assert winner, and so we
            transition to NoInfo state and perform Actions A4 (below).
            This includes sending a "canceling assert" with an infinite
            metric.















Fenner, et al.               Standards Track                   [Page 82]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from "I am Assert Loser" State

   When in "I am Assert Loser" state, the following transitions can
   occur:

      Receive Preferred Assert
            We receive an assert that is better than that of the current
            assert winner.  We stay in Loser state and perform
            Actions A2 below.

      Receive Acceptable Assert with RPTbit clear from Current Winner
            We receive an assert from the current assert winner that is
            better than our own metric for this (S,G) (although the
            metric may be worse than the winner's previous metric).  We
            stay in Loser state and perform Actions A2 below.

      Receive Inferior Assert or Assert Cancel from Current Winner
            We receive an assert from the current assert winner that is
            worse than our own metric for this group (typically, because
            the winner's metric became worse or because it is an assert
            cancel).  We transition to NoInfo state, deleting the (S,G)
            assert information and allowing the normal PIM Join/Prune
            mechanisms to operate.  Usually, we will eventually
            re-assert and win when data packets from S have started
            flowing again.

      Assert Timer Expires
            The (S,G) Assert Timer expires.  We transition to NoInfo
            state, deleting the (S,G) assert information (Actions A5
            below).

      Current Winner's GenID Changes or NLT Expires
            The Neighbor Liveness Timer associated with the current
            winner expires or we receive a Hello message from the
            current winner reporting a different GenID from the one it
            previously reported.  This indicates that the current
            winner's interface or router has gone down (and may have
            come back up), and so we must assume that it no longer knows
            it was the winner.  We transition to the NoInfo state,
            deleting this (S,G) assert information (Actions A5 below).

      AssertTrackingDesired(S,G,I)->FALSE
            AssertTrackingDesired(S,G,I) becomes FALSE.  Our forwarding
            state has changed so that (S,G) Asserts on interface I are
            no longer of interest to us.  We transition to the NoInfo
            state, deleting the (S,G) assert information.





Fenner, et al.               Standards Track                   [Page 83]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      My metric becomes better than the assert winner's metric
            my_assert_metric(S,G,I) has changed so that now my assert
            metric for (S,G) is better than the metric we have stored
            for the current assert winner.  This might happen when the
            underlying routing metric changes, or when
            CouldAssert(S,G,I) becomes true, for example, when
            SPTbit(S,G) becomes true.  We transition to NoInfo state,
            delete this (S,G) assert state (Actions A5 below), and allow
            the normal PIM Join/Prune mechanisms to operate.  Usually,
            we will eventually re-assert and win when data packets from
            S have started flowing again.

      RPF_interface(S) stops being interface I
            Interface I used to be the RPF interface for S, and now it
            is not.  We transition to NoInfo state, deleting this (S,G)
            assert state (Actions A5 below).

      Receive Join(S,G) on Interface I
            We receive a Join(S,G) that has the Upstream Neighbor
            Address field set to my primary IP address on interface I.
            The action is to transition to NoInfo state, delete this
            (S,G) assert state (Actions A5 below), and allow the normal
            PIM Join/Prune mechanisms to operate.  If whoever sent the
            Join was in error, then the normal assert mechanism will
            eventually re-apply, and we will lose the assert again.
            However, whoever sent the assert may know that the previous
            assert winner has died, and so we may end up being the new
            forwarder.

   (S,G) Assert State Machine Actions

      A1: Send Assert(S,G).
          Set Assert Timer to (Assert_Time - Assert_Override_Interval).
          Store self as AssertWinner(S,G,I).
          Store spt_assert_metric(S,I) as AssertWinnerMetric(S,G,I).

      A2: Store new assert winner as AssertWinner(S,G,I) and assert
          winner metric as AssertWinnerMetric(S,G,I).
          Set Assert Timer to Assert_Time.

      A3: Send Assert(S,G).
          Set Assert Timer to (Assert_Time - Assert_Override_Interval).

      A4: Send AssertCancel(S,G).
          Delete assert information (AssertWinner(S,G,I) and
          AssertWinnerMetric(S,G,I) will then return to their default
          values).




Fenner, et al.               Standards Track                   [Page 84]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      A5: Delete assert information (AssertWinner(S,G,I) and
          AssertWinnerMetric(S,G,I) will then return to their default
          values).

      A6: Store new assert winner as AssertWinner(S,G,I) and assert
          winner metric as AssertWinnerMetric(S,G,I).
          Set Assert Timer to Assert_Time.
          If (I is RPF_interface(S)) AND (UpstreamJPState(S,G) ==
          Joined) set SPTbit(S,G) to TRUE.

   Note that some of these actions may cause the value of
   JoinDesired(S,G), PruneDesired(S,G,rpt), or RPF'(S,G) to change,
   which could cause further transitions in other state machines.

4.6.2.  (*,G) Assert Message State Machine

   The (*,G) Assert state machine for interface I is shown in Figure 9.
   There are three states:

      NoInfo (NI)
            This router has no (*,G) assert state on interface I.

      I am Assert Winner (W)
            This router has won a (*,G) assert on interface I.  It is
            now responsible for forwarding traffic destined for G onto
            interface I with the exception of traffic for which it has
            (S,G) "I am Assert Loser" state.  Irrespective of whether it
            is the DR for I, it is also responsible for handling the
            membership requests for G from local hosts on I.

      I am Assert Loser (L)
            This router has lost a (*,G) assert on interface I.  It must
            not forward packets for G onto interface I with the
            exception of traffic from sources for which it has (S,G) "I
            am Assert Winner" state.  If it is the DR, it is no longer
            responsible for handling the membership requests for group G
            from local hosts on I.

   In addition, there is also an Assert Timer (AT) that is used to time
   out asserts on the assert losers and to resend asserts on the assert
   winner.

   When an Assert message is received with a source address other than
   zero, a PIM implementation must first match it against the possible
   events in the (S,G) assert state machine and process any transitions
   and actions, before considering whether the Assert message matches
   against the (*,G) assert state machine.




Fenner, et al.               Standards Track                   [Page 85]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   It is important to note that NO TRANSITION CAN OCCUR in the (*,G)
   state machine as a result of receiving an Assert message unless the
   (S,G) assert state machine for the relevant S and G is in the
   "NoInfo" state after the (S,G) state machine has processed the
   message.  Also, NO TRANSITION CAN OCCUR in the (*,G) state machine as
   a result of receiving an assert message if that message triggers any
   change of state in the (S,G) state machine.  Obviously, when the
   source address in the received message is set to zero, an (S,G) state
   machine for the S and G does not exist and can be assumed to be in
   the "NoInfo" state.

   For example, if both the (S,G) and (*,G) assert state machines are in
   the NoInfo state when an Assert message arrives, and the message
   causes the (S,G) state machine to transition to either "W" or "L"
   state, then the assert will not be processed by the (*,G) assert
   state machine.

   Another example: if the (S,G) assert state machine is in "L" state
   when an assert message is received, and the assert metric in the
   message is worse than my_assert_metric(S,G,I), then the (S,G) assert
   state machine will transition to NoInfo state.  In such a case, if
   the (*,G) assert state machine were in NoInfo state, it might appear
   that it would transition to "W" state, but this is not the case
   because this message already triggered a transition in the (S,G)
   assert state machine.


























Fenner, et al.               Standards Track                   [Page 86]

RFC 7761             PIM-SM Specification (Revised)           March 2016


           Figure 9: Per-Interface (*,G) Assert State Machine

+----------------------------------------------------------------------+
|                         In NoInfo (NI) State                         |
+-----------------------+-----------------------+----------------------+
| Receive Inferior      |  Data arrives for G   |  Receive Acceptable  |
| Assert with RPTbit    |  on I and             |  Assert with RPTbit  |
| set and               |  CouldAssert          |  set and AssTrDes    |
| CouldAssert(*,G,I)    |  (*,G,I)              |  (*,G,I)             |
+-----------------------+-----------------------+----------------------+
| -> W state            |  -> W state           |  -> L state          |
| [Actions A1]          |  [Actions A1]         |  [Actions A2]        |
+-----------------------+-----------------------+----------------------+

+---------------------------------------------------------------------+
|                    In I Am Assert Winner (W) State                  |
+----------------+-----------------+-----------------+----------------+
| Assert Timer   |  Receive        |  Receive        |  CouldAssert   |
| Expires        |  Inferior       |  Preferred      |  (*,G,I) ->    |
|                |  Assert         |  Assert         |  FALSE         |
+----------------+-----------------+-----------------+----------------+
| -> W state     |  -> W state     |  -> L state     |  -> NI state   |
| [Actions A3]   |  [Actions A3]   |  [Actions A2]   |  [Actions A4]  |
+----------------+-----------------+-----------------+----------------+

+---------------------------------------------------------------------+
|                    In I Am Assert Loser (L) State                   |
+-------------+-------------+-------------+-------------+-------------+
|Receive      |Receive      |Receive      |Assert Timer |Current      |
|Preferred    |Acceptable   |Inferior     |Expires      |Winner's     |
|Assert with  |Assert from  |Assert or    |             |GenID        |
|RPTbit set   |Current      |Assert       |             |Changes or   |
|             |Winner with  |Cancel from  |             |NLT Expires  |
|             |RPTbit set   |Current      |             |             |
|             |             |Winner       |             |             |
+-------------+-------------+-------------+-------------+-------------+
|-> L state   |-> L state   |-> NI state  |-> NI state  |-> NI state  |
|[Actions A2] |[Actions A2] |[Actions A5] |[Actions A5] |[Actions A5] |
+-------------+-------------+-------------+-------------+-------------+












Fenner, et al.               Standards Track                   [Page 87]

RFC 7761             PIM-SM Specification (Revised)           March 2016


+----------------------------------------------------------------------+
|                    In I Am Assert Loser (L) State                    |
+----------------+----------------+-----------------+------------------+
| AssTrDes       | my_metric ->   |  RPF_interface  |  Receive         |
| (*,G,I) ->     | better than    |  (RP(G)) stops  |  Join(*,G) on    |
| FALSE          | Winner's       |  being I        |  Interface I     |
|                | metric         |                 |                  |
+----------------+----------------+-----------------+------------------+
| -> NI state    | -> NI state    |  -> NI state    |  -> NI State     |
| [Actions A5]   | [Actions A5]   |  [Actions A5]   |  [Actions A5]    |
+----------------+----------------+-----------------+------------------+

   The state machine uses the following macros:

      CouldAssert(*,G,I) =
          ( I in ( joins(*,G) (+) pim_include(*,G)) )
          AND (RPF_interface(RP(G)) != I)

   CouldAssert(*,G,I) is true on downstream interfaces for which we have
   (*,G) join state, or local members that requested any traffic
   destined for G.

      AssertTrackingDesired(*,G,I) =
          CouldAssert(*,G,I)
          OR (local_receiver_include(*,G,I)==TRUE
              AND (I_am_DR(I) OR AssertWinner(*,G,I) == me))
          OR (RPF_interface(RP(G)) == I AND RPTJoinDesired(G))

   AssertTrackingDesired(*,G,I) is true on any interface on which a
   (*,G) assert might affect the router's behavior on that interface.

   Note that for reasons of compactness, "AssTrDes(*,G,I)" is used in
   the state machine table to refer to AssertTrackingDesired(*,G,I).

   Terminology:

      A "preferred assert" is one with a better metric than the current
      winner.

      An "acceptable assert" is one that has a better metric than
      my_assert_metric(*,G,I).  An assert is never considered acceptable
      if its metric is infinite.

      An "inferior assert" is one with a worse metric than
      my_assert_metric(*,G,I).  An assert is never considered inferior
      if my_assert_metric(*,G,I) is infinite.





Fenner, et al.               Standards Track                   [Page 88]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from NoInfo State

   When in NoInfo state, the following events trigger transitions, but
   only if the (S,G) assert state machine is in NoInfo state before and
   after consideration of the received message:

      Receive Inferior Assert with RPTbit set AND
         CouldAssert(*,G,I)==TRUE
            An Inferior (*,G) assert is received for G on Interface I.
            If CouldAssert(*,G,I) is TRUE, then I is our downstream
            interface, and we have (*,G) forwarding state on this
            interface, so we should be the assert winner.  We transition
            to the "I am Assert Winner" state and perform Actions A1
            (below).

      A data packet destined for G arrives on interface I, AND
         CouldAssert(*,G,I)==TRUE
            A data packet destined for G arrived on a downstream
            interface that is in our (*,G) outgoing interface list.  We
            therefore believe we should be the forwarder for this (*,G),
            and so we transition to the "I am Assert Winner" state and
            perform Actions A1 (below).

      Receive Acceptable Assert with RPT bit set AND
         AssertTrackingDesired(*,G,I)==TRUE
            We're interested in (*,G) Asserts, either because I is a
            downstream interface for which we have (*,G) forwarding
            state, or because I is the upstream interface for RP(G) and
            we have (*,G) forwarding state.  We get a (*,G) Assert that
            has a better metric than our own, so we do not win the
            Assert.  We transition to "I am Assert Loser" and perform
            Actions A2 (below).



















Fenner, et al.               Standards Track                   [Page 89]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from "I am Assert Winner" State

   When in "I am Assert Winner" state, the following events trigger
   transitions, but only if the (S,G) assert state machine is in NoInfo
   state before and after consideration of the received message:

      Receive Inferior Assert
            We receive a (*,G) assert that has a worse metric than our
            own.  Whoever sent the assert has lost, and so we resend a
            (*,G) Assert and restart the Assert Timer (Actions A3
            below).

      Receive Preferred Assert
            We receive a (*,G) assert that has a better metric than our
            own.  We transition to "I am Assert Loser" state and perform
            Actions A2 (below).

   When in "I am Assert Winner" state, the following events trigger
   transitions:

      Assert Timer Expires
            The (*,G) Assert Timer expires.  As we're in the Winner
            state, then we must still have (*,G) forwarding state that
            is actively being kept alive.  To prevent unnecessary
            thrashing of the forwarder and periodic flooding of
            duplicate packets, we resend the (*,G) Assert and restart
            the Assert Timer (Actions A3 below).

      CouldAssert(*,G,I) -> FALSE
            Our (*,G) forwarding state or RPF interface changed so as to
            make CouldAssert(*,G,I) become false.  We can no longer
            perform the actions of the assert winner, and so we
            transition to NoInfo state and perform Actions A4 (below).


















Fenner, et al.               Standards Track                   [Page 90]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Transitions from "I am Assert Loser" State

   When in "I am Assert Loser" state, the following events trigger
   transitions, but only if the (S,G) assert state machine is in NoInfo
   state before and after consideration of the received message:

      Receive Preferred Assert with RPTbit set
            We receive a (*,G) assert that is better than that of the
            current assert winner.  We stay in Loser state and perform
            Actions A2 below.

      Receive Acceptable Assert from Current Winner with RPTbit set
            We receive a (*,G) assert from the current assert winner
            that is better than our own metric for this group (although
            the metric may be worse than the winner's previous metric).
            We stay in Loser state and perform Actions A2 below.

      Receive Inferior Assert or Assert Cancel from Current Winner
            We receive an assert from the current assert winner that is
            worse than our own metric for this group (typically because
            the winner's metric became worse or is now an assert
            cancel).  We transition to NoInfo state, delete this (*,G)
            assert state (Actions A5), and allow the normal PIM
            Join/Prune mechanisms to operate.  Usually, we will
            eventually re-assert and win when data packets for G have
            started flowing again.

   When in "I am Assert Loser" state, the following events trigger
   transitions:

      Assert Timer Expires
            The (*,G) Assert Timer expires.  We transition to NoInfo
            state and delete this (*,G) assert information (Actions A5).

      Current Winner's GenID Changes or NLT Expires
            The Neighbor Liveness Timer associated with the current
            winner expires or we receive a Hello message from the
            current winner reporting a different GenID from the one it
            previously reported.  This indicates that the current
            winner's interface or router has gone down (and may have
            come back up), and so we must assume that it no longer knows
            it was the winner.  We transition to the NoInfo state,
            deleting the (*,G) assert information (Actions A5).








Fenner, et al.               Standards Track                   [Page 91]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      AssertTrackingDesired(*,G,I)->FALSE
            AssertTrackingDesired(*,G,I) becomes FALSE.  Our forwarding
            state has changed so that (*,G) Asserts on interface I are
            no longer of interest to us.  We transition to NoInfo state
            and delete this (*,G) assert information (Actions A5).

      My metric becomes better than the assert winner's metric
            My routing metric, rpt_assert_metric(G,I), has changed so
            that now my assert metric for (*,G) is better than the
            metric we have stored for the current assert winner.  We
            transition to NoInfo state, delete this (*,G) assert state
            (Actions A5), and allow the normal PIM Join/Prune mechanisms
            to operate.  Usually, we will eventually re-assert and win
            when data packets for G have started flowing again.

      RPF_interface(RP(G)) stops being interface I
            Interface I used to be the RPF interface for RP(G), and now
            it is not.  We transition to NoInfo state and delete this
            (*,G) assert state (Actions A5).

      Receive Join(*,G) on interface I
            We receive a Join(*,G) that has the Upstream Neighbor
            Address field set to my primary IP address on interface I.
            The action is to transition to NoInfo state, delete this
            (*,G) assert state (Actions A5), and allow the normal PIM
            Join/Prune mechanisms to operate.  If whoever sent the Join
            was in error, then the normal assert mechanism will
            eventually re-apply, and we will lose the assert again.
            However, whoever sent the assert may know that the previous
            assert winner has died, so we may end up being the new
            forwarder.

   (*,G) Assert State Machine Actions

      A1: Send Assert(*,G).
          Set Assert Timer to (Assert_Time - Assert_Override_Interval).
          Store self as AssertWinner(*,G,I).
          Store rpt_assert_metric(G,I) as AssertWinnerMetric(*,G,I).

      A2: Store new assert winner as AssertWinner(*,G,I) and assert
          winner metric as AssertWinnerMetric(*,G,I).
          Set Assert Timer to Assert_Time.

      A3: Send Assert(*,G).
          Set Assert Timer to (Assert_Time - Assert_Override_Interval).






Fenner, et al.               Standards Track                   [Page 92]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      A4: Send AssertCancel(*,G).
          Delete assert information (AssertWinner(*,G,I) and
          AssertWinnerMetric(*,G,I) will then return to their default
          values).

      A5: Delete assert information (AssertWinner(*,G,I) and
          AssertWinnerMetric(*,G,I) will then return to their default
          values).

   Note that some of these actions may cause the value of
   JoinDesired(*,G) or RPF'(*,G) to change, which could cause further
   transitions in other state machines.

4.6.3.  Assert Metrics

   Assert metrics are defined as:

     struct assert_metric {
       rpt_bit_flag;
       metric_preference;
       route_metric;
       ip_address;
     };

   When comparing assert_metrics, the rpt_bit_flag, metric_preference,
   and route_metric fields are compared in order, where the first lower
   value wins.  If all fields are equal, the primary IP address of the
   router that sourced the Assert message is used as a tie-breaker, with
   the highest IP address winning.

   An assert metric for (S,G) to include in (or compare against) an
   Assert message sent on interface I should be computed using the
   following pseudocode:

     assert_metric
     my_assert_metric(S,G,I) {
         if( CouldAssert(S,G,I) == TRUE ) {
             return spt_assert_metric(S,I)
         } else if( CouldAssert(*,G,I) == TRUE ) {
             return rpt_assert_metric(G,I)
         } else {
             return infinite_assert_metric()
         }
     }







Fenner, et al.               Standards Track                   [Page 93]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   spt_assert_metric(S,I) gives the assert metric we use if we're
   sending an assert based on active (S,G) forwarding state:

     assert_metric
     spt_assert_metric(S,I) {
        return {0,MRIB.pref(S),MRIB.metric(S),my_ip_address(I)}
     }

   rpt_assert_metric(G,I) gives the assert metric we use if we're
   sending an assert based only on (*,G) forwarding state:

     assert_metric
     rpt_assert_metric(G,I) {
         return {1,MRIB.pref(RP(G)),MRIB.metric(RP(G)),my_ip_address(I)}
     }

   MRIB.pref(X) and MRIB.metric(X) are the routing preference and
   routing metrics associated with the route to a particular (unicast)
   destination X, as determined by the MRIB.  my_ip_address(I) is simply
   the router's primary IP address that is associated with the local
   interface I.

   infinite_assert_metric() is an assert metric that the router uses for
   an Assert that does not match either (S,G) or (*,G) forwarding state:

     assert_metric
     infinite_assert_metric() {
          return {1,infinity,infinity,0}
     }

4.6.4.  AssertCancel Messages

   An AssertCancel message is simply an RPT Assert message but with an
   infinite metric.  It is sent by the assert winner when it deletes the
   forwarding state that had caused the assert to occur.  Other routers
   will see this metric, and it will cause any other router that has
   forwarding state to send its own assert, and to take over forwarding.

   An AssertCancel(S,G) is an infinite metric assert with the RPT bit
   set that names S as the source.

   An AssertCancel(*,G) is an infinite metric assert with the RPT bit
   set and the source set to zero.








Fenner, et al.               Standards Track                   [Page 94]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   AssertCancel messages are simply an optimization.  The original
   Assert timeout mechanism will allow a subnet to eventually become
   consistent; the AssertCancel mechanism simply causes faster
   convergence.  No special processing is required for an AssertCancel
   message, since it is simply an Assert message from the current
   winner.

4.6.5.  Assert State Macros

   The macros lost_assert(S,G,rpt,I), lost_assert(S,G,I), and
   lost_assert(*,G,I) are used in the olist computations of Section 4.1
   and are defined as:

     bool lost_assert(S,G,rpt,I) {
       if ( RPF_interface(RP(G)) == I  OR
            ( RPF_interface(S) == I AND SPTbit(S,G) == TRUE ) ) {
          return FALSE
       } else {
          return ( AssertWinner(S,G,I) != NULL AND
                   AssertWinner(S,G,I) != me )
       }
     }

     bool lost_assert(S,G,I) {
       if ( RPF_interface(S) == I ) {
          return FALSE
       } else {
          return ( AssertWinner(S,G,I) != NULL AND
                   AssertWinner(S,G,I) != me  AND
                   (AssertWinnerMetric(S,G,I) is better
                      than spt_assert_metric(S,I) )
       }
     }

   Note: The term "AssertWinnerMetric(S,G,I) is better than
   spt_assert_metric(S,I)" is required to correctly handle the
   transition phase when a router has (S,G) join state but has not yet
   set the SPTbit.  In this case, it needs to ignore the assert state if
   it will win the assert once the SPTbit is set.

     bool lost_assert(*,G,I) {
       if ( RPF_interface(RP(G)) == I ) {
          return FALSE
       } else {
          return ( AssertWinner(*,G,I) != NULL AND
                   AssertWinner(*,G,I) != me )
       }
     }



Fenner, et al.               Standards Track                   [Page 95]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   AssertWinner(S,G,I) is the IP source address of the Assert(S,G)
   packet that won an Assert.

   AssertWinner(*,G,I) is the IP source address of the Assert(*,G)
   packet that won an Assert.

   AssertWinnerMetric(S,G,I) is the Assert metric of the Assert(S,G)
   packet that won an Assert.

   AssertWinnerMetric(*,G,I) is the Assert metric of the Assert(*,G)
   packet that won an Assert.

   AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I)
   defaults to Infinity when in the NoInfo state.

   Summary of Assert Rules and Rationale

   This section summarizes the key rules for sending and reacting to
   asserts and the rationale for these rules.  This section is not
   intended to be and should not be treated as a definitive
   specification of protocol behavior.  The state machines and
   pseudocode should be consulted for that purpose.  Rather, this
   section is intended to document important aspects of the Assert
   protocol behavior and to provide information that may prove helpful
   to the reader in understanding and implementing this part of the
   protocol.

   1.  Behavior: Downstream neighbors send Join(*,G) and Join(S,G)
       periodic messages to the appropriate RPF' neighbor, i.e., the RPF
       neighbor as modified by the assert process.  They are not always
       sent to the RPF neighbor as indicated by the MRIB.  Normal
       suppression and override rules apply.

       Rationale: By sending the periodic and triggered Join messages to
       the RPF' neighbor instead of the RPF neighbor, the downstream
       router avoids re-triggering the Assert process with every Join.
       A side effect of sending Joins to the Assert winner is that
       traffic will not switch back to the "normal" RPF neighbor until
       the Assert times out.  This will not happen until data stops
       flowing, if item 8, below, is implemented.

   2.  Behavior: The assert winner for (*,G) acts as the local DR for
       (*,G) on behalf of IGMP/MLD members.

       Rationale: This is required to allow a single router to merge
       PIM and IGMP/MLD joins and leaves.  Without this, overrides
       don't work.




Fenner, et al.               Standards Track                   [Page 96]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   3.  Behavior: The assert winner for (S,G) acts as the local DR for
       (S,G) on behalf of IGMPv3 members.

       Rationale: Same rationale as for item 2.

   4.  Behavior: (S,G) and (*,G) prune overrides are sent to the RPF'
       neighbor and not to the regular RPF neighbor.

       Rationale: Same rationale as for item 1.

   5.  Behavior: An (S,G,rpt) prune override is not sent (at all) if
       RPF'(S,G,rpt) != RPF'(*,G).

       Rationale: This avoids keeping state alive on the (S,G) tree when
       only (*,G) downstream members are left.  Also, it avoids sending
       (S,G,rpt) joins to a router that is not on the (*,G) tree.  This
       behavior might be confusing, although this specification does
       indicate that such a join SHOULD be dropped.

   6.  Behavior: An assert loser that receives a Join(S,G) with an
       Upstream Neighbor Address that is its primary IP address on that
       interface expires the (S,G) Assert Timer.

       Rationale: This is necessary in order to have rapid convergence
       in the event that the downstream router that initially sent a
       join to the prior Assert winner has undergone a topology change.

   7.  Behavior: An assert loser that receives a Join(*,G) with an
       Upstream Neighbor Address that is its primary IP address on that
       interface expires the (*,G) Assert Timer and all (S,G) assert
       timers that do not have corresponding Prune(S,G,rpt) messages in
       the compound Join/Prune message.

       Rationale: Same rationale as for item 6.

   8.  Behavior: An assert winner for (*,G) or (S,G) sends a canceling
       assert when it is about to stop forwarding on a (*,G) or an (S,G)
       entry.  This behavior does not apply to (S,G,rpt).

       Rationale: This allows switching back to the shared tree after
       the last SPT router on the LAN leaves.  Doing this prevents
       downstream routers on the shared tree from keeping SPT state
       alive.








Fenner, et al.               Standards Track                   [Page 97]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   9.  Behavior: Resend the assert messages before timing out an assert.
       (This behavior is optional.)

       Rationale: This prevents the periodic duplicates that would
       otherwise occur each time that an assert times out and is then
       re-established.

   10. Behavior: When RPF'(S,G,rpt) changes to be the same as RPF'(*,G),
       we need to trigger a Join(S,G,rpt) to RPF'(*,G).

       Rationale: This allows switching back to the RPT after the last
       SPT member leaves.

4.7.  PIM Bootstrap and RP Discovery

   For correct operation, every PIM router within a PIM domain must be
   able to map a particular multicast group address to the same RP.  If
   this is not the case, then black holes may appear, where some
   receivers in the domain cannot receive some groups.  A domain in this
   context is a contiguous set of routers that all implement PIM and are
   configured to operate within a common boundary.

   A notable exception to this is where a PIM domain is broken up into
   multiple administrative scope regions; these are regions where a
   border has been configured so that a range of multicast groups will
   not be forwarded across that border.  For more information on
   Administratively Scoped IP Multicast, see RFC 2365.  The modified
   criteria for admin-scoped regions are that the region is convex with
   respect to forwarding based on the MRIB, and that all PIM routers
   within the scope region map scoped groups to the same RP within that
   region.

   This specification does not mandate the use of a single mechanism to
   provide routers with the information to perform the group-to-RP
   mapping.  Currently, four mechanisms are possible, and all four have
   associated problems:

   Static Configuration
         A PIM router MUST support the static configuration of group-to-
         RP mappings.  Such a mechanism is not robust to failures but
         does at least provide a basic interoperability mechanism.

   Embedded-RP
         Embedded-RP defines an address allocation policy in which the
         address of the Rendezvous Point (RP) is encoded in an IPv6
         multicast group address [16].





Fenner, et al.               Standards Track                   [Page 98]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Cisco's Auto-RP
         Auto-RP uses a PIM Dense-Mode (PIM-DM) multicast group to
         announce group-to-RP mappings from a central location.  This
         mechanism is not useful if PIM Dense Mode is not being run in
         parallel with PIM Sparse Mode; it was only intended for use
         with PIM Sparse Mode Version 1.  No standard specification
         currently exists.

   Bootstrap Router (BSR)
         RFC 2362 specifies a bootstrap mechanism based on the automatic
         election of a BSR.  Any router in the domain that is configured
         to be a possible RP reports its candidacy to the BSR, and then
         a domain-wide flooding mechanism distributes the BSR's chosen
         set of RPs throughout the domain.  As specified in RFC 2362,
         the BSR mechanism is flawed in its handling of admin-scoped
         regions that are smaller than a PIM domain, but the mechanism
         does work for global-scoped groups.

   As far as PIM-SM is concerned, the only important requirement is that
   all routers in the domain (or admin scope zone for scoped regions)
   receive the same set of group-range-to-RP mappings.  This may be
   achieved through the use of any of these mechanisms, or through
   alternative mechanisms not currently specified.

   It must be operationally ensured that any RP address configured,
   learned, or advertised is reachable from all routers in the PIM
   domain.

4.7.1.  Group-to-RP Mapping

   Using one of the mechanisms described above, a PIM router receives
   one or more possible group-range-to-RP mappings.  Each mapping
   specifies a range of multicast groups (expressed as a group and mask)
   and the RP to which such groups should be mapped.  Each mapping may
   also have an associated priority.  It is possible to receive multiple
   mappings, all of which might match the same multicast group; this is
   the common case with the BSR mechanism.  The algorithm for performing
   the group-to-RP mapping is as follows:

   1.  Perform longest match on group range to obtain a list of RPs.

   2.  From this list of matching RPs, find the ones with highest
       priority.

       Eliminate any RPs from the list that have lower priorities.






Fenner, et al.               Standards Track                   [Page 99]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   3.  If only one RP remains in the list, use that RP.

   4.  If multiple RPs are in the list, use the PIM hash function to
       choose one.

   Thus, if two or more group-range-to-RP mappings cover a particular
   group, the one with the longest mask is the mapping to use.  If the
   mappings have the same mask length, then the one with the highest
   priority is chosen.  If there is more than one matching entry with
   the same longest mask and the priorities are identical, then a hash
   function (see Section 4.7.2) is applied to choose the RP.

   This algorithm is invoked by a DR when it needs to determine an RP
   for a given group, e.g., upon reception of a packet or IGMP/MLD
   membership indication for a group for which the DR does not know
   the RP.

   Furthermore, the mapping function is invoked by all routers upon
   receiving a (*,G) Join/Prune message.

   Note that if the set of possible group-range-to-RP mappings changes,
   each router will need to check whether any existing groups are
   affected.  This may, for example, cause a DR or acting DR to re-join
   a group, or cause it to restart register encapsulation to the new RP.

      Implementation note: The bootstrap mechanism described in RFC 2362
      omitted step 1 above.  However, of the implementations we are
      aware of, approximately half performed step 1 anyway.  Note that
      implementations of BSR that omit step 1 will not correctly
      interoperate with implementations of this specification when used
      with the BSR mechanism described in [11].

4.7.2.  Hash Function

   The hash function is used by all routers within a domain, to map a
   group to one of the RPs from the matching set of group-range-to-RP
   mappings (this set of mappings all have the same longest mask length
   and same highest priority).  The algorithm takes as input the group
   address, and the addresses of the candidate RPs from the mappings,
   and gives as output one RP address to be used.











Fenner, et al.               Standards Track                  [Page 100]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The protocol requires that all routers hash to the same RP within a
   domain (except for transients).  The following hash function must be
   used in each router:

   1.  For RP addresses in the matching group-range-to-RP mappings,
       compute a value:

   Value(G,M,C(i))=
   (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31

       where C(i) is the RP address and M is a hash-mask.  If BSR is
       being used, the hash-mask is given in the Bootstrap messages.  If
       BSR is not being used, the alternative mechanism that supplies
       the group-range-to-RP mappings may supply the value, or else it
       defaults to a mask with the most significant 30 bits being one
       for IPv4 and the most significant 126 bits being one for IPv6.
       The hash-mask allows a small number of consecutive groups
       (e.g., 4) to always hash to the same RP.  For instance,
       hierarchically encoded data can be sent on consecutive group
       addresses to get the same delay and fate-sharing characteristics.

       For address families other than IPv4, a 32-bit digest to be used
       as C(i) and G must first be derived from the actual RP or group
       address.  Such a digest method must be used consistently
       throughout the PIM domain.  For IPv6 addresses, it is RECOMMENDED
       to use the equivalent IPv4 address for an IPv4-compatible
       address, and the exclusive-or of each 32-bit segment of the
       address for all other IPv6 addresses.  For example, the digest of
       the IPv6 address 3ffe:b00:c18:1::10 would be computed as
       0x3ffe0b00 ^ 0x0c180001 ^ 0x00000000 ^ 0x00000010,
       where the '^' symbol represents the exclusive-or operation.

   2.  The candidate RP with the highest resulting hash value is then
       the RP chosen by this hash function.  If more than one RP has the
       same highest hash value, the RP with the highest IP address is
       chosen.

4.8.  Source-Specific Multicast

   The Source-Specific Multicast (SSM) service model [6] can be
   implemented with a strict subset of the PIM-SM protocol mechanisms.
   Both regular IP Multicast and SSM semantics can coexist on a single
   router, and both can be implemented using the PIM-SM protocol.  A
   range of multicast addresses, currently 232.0.0.0/8 in IPv4 and
   ff3x::/32 for IPv6, is reserved for SSM, and the choice of semantics
   is determined by the multicast group address in both data packets and
   PIM messages.




Fenner, et al.               Standards Track                  [Page 101]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.8.1.  Protocol Modifications for SSM Destination Addresses

   The following rules override the normal PIM-SM behavior for a
   multicast address G in the SSM range:

   o  A router MUST NOT send a (*,G) Join/Prune message for any reason.

   o  A router MUST NOT send an (S,G,rpt) Join/Prune message for any
      reason.

   o  A router MUST NOT send a Register message for any packet that is
      destined to an SSM address.

   o  A router MUST NOT forward packets based on (*,G) or (S,G,rpt)
      state.  The (*,G)- and (S,G,rpt)-related state summarization
      macros are NULL for any SSM address, for the purposes of packet
      forwarding.

   o  A router acting as an RP MUST NOT forward any Register-
      encapsulated packet that has an SSM destination address and SHOULD
      respond with a Register-Stop message to such a Register message.

   o  A router MAY optimize out the creation and maintenance of
      (S,G,rpt) and (*,G) state for SSM destination addresses -- this
      state is not needed for SSM packets.

   The last three rules are present to deal with SSM-unaware "legacy"
   routers that may be sending (*,G) and (S,G,rpt) Join/Prunes, or
   Register messages for SSM destination addresses.  Note that this
   specification does not attempt to aid an SSM-unaware "legacy" router
   with SSM operations.

4.8.2.  PIM-SSM-Only Routers

   An implementer may choose to implement only the subset of PIM
   Sparse Mode that provides SSM forwarding semantics.

   A PIM-SSM-only router MUST implement the following portions of this
   specification:

   o  Upstream (S,G) state machine (Section 4.5.5)

   o  Downstream (S,G) state machine (Section 4.5.2)

   o  (S,G) Assert state machine (Section 4.6.1)






Fenner, et al.               Standards Track                  [Page 102]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   o  Hello messages, neighbor discovery, and DR election (Section 4.3)

   o  Packet forwarding rules (Section 4.2)

   A PIM-SSM-only router does not need to implement the following
   protocol elements:

   o  Register state machine (Section 4.4)

   o  (*,G) and (S,G,rpt) downstream state machines (Sections 4.5.1 and
      4.5.3)

   o  (*,G) and (S,G,rpt) upstream state machines (Sections 4.5.4,
      4.5.6, and 4.5.7)

   o  (*,G) Assert state machine (Section 4.6.2)

   o  Bootstrap RP election (Section 4.7)

   o  Keepalive Timer

   o  SPTbit (Section 4.2.2)

   The Keepalive Timer should be treated as always running, and the
   SPTbit should be treated as always being set for an SSM address.
   Additionally, the packet forwarding rules of Section 4.2 can be
   simplified in a PIM-SSM-only router:

     oiflist = NULL

     if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {
         oiflist = inherited_olist(S,G)
     } else if( iif is in inherited_olist(S,G) ) {
         send Assert(S,G) on iif
     }

     oiflist = oiflist (-) iif
     forward packet on all interfaces in oiflist

   This is nothing more than the reduction of the normal PIM-SM
   forwarding rule, with all (S,G,rpt) and (*,G) clauses replaced
   with NULL.









Fenner, et al.               Standards Track                  [Page 103]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.9.  PIM Packet Formats

   This section describes the details of the packet formats for PIM
   control messages.

   All PIM control messages have IP protocol number 103.

   PIM messages are either unicast (e.g., Registers and Register-Stop)
   or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g.,
   Join/Prune, Asserts).  The source address used for unicast messages
   is a domain-wide reachable address; the source address used for
   multicast messages is the link-local address of the interface on
   which the message is being sent.

   The IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13'.  The IPv6
   'ALL-PIM-ROUTERS' group is 'ff02::d'.

   The PIM header common to all PIM messages is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Ver
         PIM Version number is 2.

   Type
         Types for specific PIM messages.  PIM Types are:

   Message Type                          Destination
   ---------------------------------------------------------------------
   0 = Hello                             Multicast to ALL-PIM-ROUTERS
   1 = Register                          Unicast to RP
   2 = Register-Stop                     Unicast to source of Register
                                            packet
   3 = Join/Prune                        Multicast to ALL-PIM-ROUTERS
   4 = Bootstrap                         Multicast to ALL-PIM-ROUTERS
   5 = Assert                            Multicast to ALL-PIM-ROUTERS
   6 = Graft (used in PIM-DM only)       Unicast to RPF'(S)
   7 = Graft-Ack (used in PIM-DM only)   Unicast to source of Graft
                                            packet
   8 = Candidate-RP-Advertisement        Unicast to Domain's BSR







Fenner, et al.               Standards Track                  [Page 104]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Reserved
         Set to zero on transmission.  Ignored upon receipt.

   Checksum
         The checksum is a standard IP checksum, i.e., the 16-bit one's
         complement of the one's complement sum of the entire PIM
         message, excluding the "Multicast data packet" section of the
         Register message.  For computing the checksum, the checksum
         field is zeroed.  If the packet's length is not an integral
         number of 16-bit words, the packet is padded with a trailing
         byte of zero before performing the checksum.

         For IPv6, the checksum also includes the IPv6 "pseudo-header",
         as specified in RFC 2460, Section 8.1 [5].  This
         "pseudo-header" is prepended to the PIM header for the purposes
         of calculating the checksum.  The "Upper-Layer Packet Length"
         in the pseudo-header is set to the length of the PIM message,
         except in Register messages where it is set to the length of
         the PIM register header (8).  The Next Header value used in the
         pseudo-header is 103.

   If a message is received with an unrecognized PIM Ver or Type field,
   or if a message's destination does not correspond to the table above,
   the message MUST be discarded, and an error message SHOULD be logged
   to the administrator in a rate-limited manner.

4.9.1.  Encoded Source and Group Address Formats

   Encoded Unicast Address

   An encoded unicast address takes the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Addr Family  | Encoding Type |     Unicast Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Addr Family
         The PIM address family of the 'Unicast Address' field of this
         address.

         Values 0-127 are as assigned by the IANA for Internet Address
         Families in [7].  Values 128-250 are reserved to be assigned by
         the IANA for PIM-specific Address Families.  Values 251 through
         255 are designated for Private Use.  As there is no assignment
         authority for this space, collisions should be expected.




Fenner, et al.               Standards Track                  [Page 105]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Encoding Type
         The type of encoding used within a specific Address Family.
         The value '0' is reserved for this field and represents the
         native encoding of the Address Family.

   Unicast Address
         The unicast address as represented by the given Address Family
         and Encoding Type.

   Encoded Group Address

   Encoded group addresses take the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Group multicast Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Addr Family
         Described above.

   Encoding Type
         Described above.

   [B]idirectional PIM
         Indicates that the group range uses Bidirectional PIM [13].
         For PIM-SM as defined in this specification, this bit MUST be
         zero.

   Reserved
         Transmitted as zero.  Ignored upon receipt.

   Admin Scope [Z]one
         Indicates that the group range is an admin scope zone.  This is
         used in the Bootstrap Router mechanism [11] only.  For all
         other purposes, this bit is set to zero and ignored on receipt.












Fenner, et al.               Standards Track                  [Page 106]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Mask Len
         The Mask length field is 8 bits.  The value is the number of
         contiguous one bits that are left-justified and used as a mask;
         when combined with the group address, it describes a range of
         groups.  It is less than or equal to the address length in bits
         for the given Address Family and Encoding Type.  If the message
         is sent for a single group, then the Mask length must equal the
         address length in bits for the given Address Family and
         Encoding Type (e.g., 32 for IPv4 native encoding, 128 for IPv6
         native encoding).

   Group multicast Address
         Contains the group address.

   Encoded Source Address

   An encoded source address takes the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Addr Family   | Encoding Type | Rsrvd   |S|W|R|  Mask Len     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

   Addr Family
         Described above.

   Encoding Type
         Described above.

   Reserved
         Transmitted as zero, ignored on receipt.

   S     The Sparse bit is a 1-bit value, set to 1 for PIM-SM.  It is
         used for PIM Version 1 compatibility.

   W     The WC (or WildCard) bit is a 1-bit value for use with PIM
         Join/Prune messages (see Section 4.9.5.1).

   R     The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
         with PIM Join/Prune messages (see Section 4.9.5.1).  If the
         WC bit is 1, the RPT bit MUST be 1.







Fenner, et al.               Standards Track                  [Page 107]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Mask Len
         The mask length field is 8 bits.  The value is the number of
         contiguous one bits that are left-justified and used as a mask;
         when combined with the source address, it describes a source
         subnet.  The mask length MUST be equal to the mask length in
         bits for the given Address Family and Encoding Type (32 for
         IPv4 native and 128 for IPv6 native).  A router SHOULD ignore
         any messages received with any other mask length.

   Source Address
         The source address.

4.9.2.  Hello Message Format

   A Hello message is sent periodically by routers on all interfaces.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OptionType           |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                               .                               |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OptionType           |         OptionLength          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          OptionValue                          |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   OptionType
         The type of the option given in the following OptionValue
         field.

   OptionLength
         The length of the OptionValue field in bytes.

   OptionValue
         A variable-length field, carrying the value of the option.



Fenner, et al.               Standards Track                  [Page 108]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   The Option fields may contain the following values:

   o  OptionType 1: Holdtime

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 1             |         Length = 2            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Holdtime             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Holdtime is the amount of time a receiver must keep the neighbor
      reachable, in seconds.  If the Holdtime is set to '0xffff', the
      receiver of this message never times out the neighbor.  This may
      be used with dial-on-demand links, to avoid keeping the link up
      with periodic Hello messages.

      An implementation MAY provide a configuration mechanism to reject
      a Hello message with holdtime 0xffff, and/or provide a mechanism
      to remove a neighbor.

      Hello messages with a Holdtime value set to '0' are also sent by a
      router on an interface about to go down or changing IP address
      (see Section 4.3.1).  These are effectively goodbye messages, and
      the receiving routers SHOULD immediately time out the neighbor
      information for the sender.

   o  OptionType 2: LAN Prune Delay

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 2             |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|      Propagation_Delay      |      Override_Interval        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The LAN Prune Delay option is used to tune the prune propagation
      delay on multi-access LANs.  The T bit specifies the ability of
      the sending router to disable Join suppression.  Propagation_Delay
      and Override_Interval are time intervals in units of milliseconds.
      A router originating a LAN Prune Delay option on interface I sets
      the Propagation_Delay field to the configured value of
      Propagation_Delay(I) and the value of the Override_Interval field
      to the value of Override_Interval(I).  On a receiving router, the
      values of the fields are used to tune the value of the
      Effective_Override_Interval(I) and its derived timer values.



Fenner, et al.               Standards Track                  [Page 109]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      Section 4.3.3 describes how these values affect the behavior of a
      router.

   o  OptionTypes 3 through 16: Reserved; to be defined in future
      versions of this document.

   o  OptionType 18: Deprecated and should not be used.

   o  OptionType 19: DR Priority

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 19            |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         DR Priority                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      DR Priority is a 32-bit unsigned number and should be considered
      in the DR election as described in Section 4.3.2.

   o  OptionType 20: Generation ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 20            |          Length = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Generation ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Generation ID is a random 32-bit value for the interface on which
      the Hello message is sent.  The Generation ID is regenerated
      whenever PIM forwarding is started or restarted on the interface.

















Fenner, et al.               Standards Track                  [Page 110]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   o  OptionType 24: Address List

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 24            |      Length = <Variable>      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Secondary Address 1 (Encoded-Unicast format)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Secondary Address N (Encoded-Unicast format)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The contents of the Address List Hello option are described in
      Section 4.3.4.  All addresses within a single Address List must
      belong to the same address family.

   OptionTypes 17 through 65000 are assigned by the IANA.
   OptionTypes 65001 through 65535 are reserved for Private Use,
   as defined in [9].

   Unknown options MUST be ignored and MUST NOT prevent a neighbor
   relationship from being formed.  The Holdtime option MUST be
   implemented; the DR Priority and Generation ID options SHOULD be
   implemented.  The Address List option MUST be implemented for IPv6.

4.9.3.  Register Message Format

   A Register message is sent by the DR to the RP when a multicast
   packet needs to be transmitted on the RP-tree.  The IP source address
   is set to the address of the DR, the destination address to the RP's
   address.  The IP TTL of the PIM packet is the system's normal
   unicast TTL.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |B|N|                       Reserved2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                     Multicast data packet                     .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Fenner, et al.               Standards Track                  [Page 111]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.  Note that in order to reduce
         encapsulation overhead, the checksum for Registers is done only
         on the first 8 bytes of the packet, including the PIM header
         and the next 4 bytes, excluding the data packet portion.  For
         interoperability reasons, a message carrying a checksum
         calculated over the entire PIM Register message should also be
         accepted.  When calculating the checksum, the IPv6
         pseudo-header "Upper-Layer Packet Length" is set to 8.

   B     The Border bit.  This specification deprecates the Border bit.
         A router MUST set the B bit to 0 on transmission and MUST
         ignore this bit on reception.

   N     The Null-Register bit.  Set to 1 by a DR that is probing the RP
         before expiring its local Register-Suppression Timer.  Set to 0
         otherwise.

   Reserved2
         Transmitted as zero, ignored on receipt.

   Multicast data packet
         The original packet sent by the source.  This packet must be of
         the same address family as the encapsulating PIM packet, e.g.,
         an IPv6 data packet must be encapsulated in an IPv6 PIM packet.
         Note that the TTL of the original packet is decremented before
         encapsulation, just like any other packet that is forwarded.
         In addition, the RP decrements the TTL after decapsulating,
         before forwarding the packet down the shared tree.

         For (S,G) Null-Registers, the Multicast data packet portion
         contains a dummy IP header with S as the source address
         and G as the destination address.  When generating an IPv4
         Null-Register message, the fields in the dummy IPv4 header
         SHOULD be filled in according to the following table.  Other
         IPv4 header fields may contain any value that is valid for
         that field.

         Field                  Value
         ---------------------------------------
         IP Version             4
         Header Length          5
         Checksum               Header checksum
         Fragmentation offset   0
         More Fragments         0
         Total Length           20
         IP Protocol            103 (PIM)




Fenner, et al.               Standards Track                  [Page 112]

RFC 7761             PIM-SM Specification (Revised)           March 2016


         On receipt of an (S,G) Null-Register, if the Header Checksum
         field is non-zero, the recipient SHOULD check the checksum and
         discard Null-Registers that have a bad checksum.  The recipient
         SHOULD NOT check the value of any individual fields; a correct
         IP header checksum is sufficient.  If the Header Checksum field
         is zero, the recipient MUST NOT check the checksum.

         With IPv6, an implementation generates a dummy IP header
         followed by a dummy PIM header with values according to the
         following table in addition to the source and group.  Other
         IPv6 header fields may contain any value that is valid for that
         field.

         Header Field   Value
         --------------------------------------
         IP Version     6
         Next Header    103 (PIM)
         Length         4
         PIM Version    0
         PIM Type       0
         PIM Reserved   0
         PIM Checksum   PIM checksum, including
                        IPv6 "pseudo-header";
                        see Section 4.9

         On receipt of an IPv6 (S,G) Null-Register, if the dummy PIM
         header is present, the recipient SHOULD check the checksum and
         discard Null-Registers that have a bad checksum.

4.9.4.  Register-Stop Message Format

   A Register-Stop is unicast from the RP to the sender of the Register
   message.  The IP source address is the address to which the register
   was addressed.  The IP destination address is the source address of
   the register message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Group Address (Encoded-Group format)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Fenner, et al.               Standards Track                  [Page 113]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   Group Address
         The group address from the multicast data packet in the
         Register.  The format for this address is described in
         Section 4.9.1.  Note that for Register-Stops the Mask Len field
         contains the full address length * 8 (e.g., 32 for IPv4 native
         encoding), if the message is sent for a single group.

   Source Address
         The host address of the source from the multicast data packet
         in the register.  The format for this address is given in the
         encoded unicast address in Section 4.9.1.  A special wildcard
         value consisting of an address field of all zeros can be used
         to indicate any source.

4.9.5.  Join/Prune Message Format

   A Join/Prune message is sent by routers towards upstream sources and
   RPs.  Joins are sent to build shared trees (RP trees) or source trees
   (SPT).  Prunes are sent to prune source trees when members leave
   groups as well as sources that do not use the shared tree.




























Fenner, et al.               Standards Track                  [Page 114]

RFC 7761             PIM-SM Specification (Revised)           March 2016


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Upstream Neighbor Address (Encoded-Unicast format)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reserved     | Num groups    |          Holdtime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address 1 (Encoded-Group format)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined Sources    |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           .                                   |
   |                           .                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast Group Address m (Encoded-Group format)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Number of Joined Sources    |   Number of Pruned Sources    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Joined Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address 1 (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             .                                 |
   |                             .                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Pruned Source Address n (Encoded-Source format)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Fenner, et al.               Standards Track                  [Page 115]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   Unicast Upstream Neighbor Address
         The primary address of the upstream neighbor that is the target
         of the message.  The format for this address is given in the
         encoded unicast address in Section 4.9.1.

   Reserved
         Transmitted as zero, ignored on receipt.

   Holdtime
         The amount of time a receiver MUST keep the Join/Prune state
         alive, in seconds.  If the Holdtime is set to '0xffff', the
         receiver of this message SHOULD hold the state until canceled
         by the appropriate canceling Join/Prune message, or timed out
         according to local policy.  This may be used with dial-on-
         demand links, to avoid keeping the link up with periodic
         Join/Prune messages.

         Note that the HoldTime MUST be larger than the
         J/P_Override_Interval(I).

   Number of Groups
         The number of multicast group sets contained in the message.

   Multicast group address
         For format description, see Section 4.9.1.

   Number of Joined Sources
         Number of joined source addresses listed for a given group.

   Joined Source Address 1 .. n
         This list contains the sources for a given group that the
         sending router will forward multicast datagrams from if
         received on the interface on which the Join/Prune message
         is sent.

         See Section 4.9.1 for the format description for the
         encoded source address.

   Number of Pruned Sources
         Number of pruned source addresses listed for a group.








Fenner, et al.               Standards Track                  [Page 116]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Pruned Source Address 1 .. n
         This list contains the sources for a given group that the
         sending router does not want to forward multicast datagrams
         from when received on the interface on which the Join/Prune
         message is sent.

   Within one PIM Join/Prune message, all the Multicast Group addresses,
   Joined Source addresses, and Pruned Source addresses MUST be of the
   same address family.  It is NOT PERMITTED to mix IPv4 and IPv6
   addresses within the same message.  In addition, the address family
   of the fields in the message SHOULD be the same as the IP source and
   destination addresses of the packet.  This permits maximum
   implementation flexibility for dual-stack IPv4/IPv6 routers.  If a
   router receives a message with mixed family addresses, it SHOULD only
   process the addresses that are of the same family as the unicast
   upstream neighbor address.

4.9.5.1.  Group Set Source List Rules

   As described above, Join/Prune messages are composed of one or more
   group sets.  Each set contains two source lists: the Joined Sources
   and the Pruned Sources.  This section describes the different types
   of group sets and source list entries that can exist in a Join/Prune
   message.

   There is one valid group set type:

   Group-Specific Set
         A Group-Specific Set is represented by a valid IP multicast
         address in the group address field and the full length of the
         IP address in the mask length field of the Multicast Group
         Address.  Each Join/Prune message SHOULD NOT contain more than
         one group-specific set for the same IP multicast address.  Each
         group-specific set may contain (*,G), (S,G,rpt), and (S,G)
         source list entries in the Joined or Pruned lists.

      (*,G)
            The (*,G) source list entry is used in Join/Prune messages
            sent towards the RP for the specified group.  It expresses
            interest (or lack thereof) in receiving traffic sent to the
            group through the RP shared tree.  There MUST only be one
            such entry in both the Joined and Pruned lists of a group-
            specific set.

            (*,G) source list entries have the Source-Address set to the
            address of the RP for group G, the Source-Address Mask-Len
            set to the full length of the IP address, and both the WC
            and RPT bits of the encoded-source-address set.



Fenner, et al.               Standards Track                  [Page 117]

RFC 7761             PIM-SM Specification (Revised)           March 2016


      (S,G,rpt)
            The (S,G,rpt) source list entry is used in Join/Prune
            messages sent towards the RP for the specified group.  It
            expresses interest (or lack thereof) in receiving traffic
            through the shared tree sent by the specified source to this
            group.  For each source address, the entry MUST exist in
            only one of the Joined and Pruned source lists of a group-
            specific set, but not both.

            (S,G,rpt) source list entries have the Source-Address set to
            the address of the source S, the Source-Address Mask-Len set
            to the full length of the IP address, and the WC bit cleared
            and the RPT bit set in the encoded source address.

      (S,G)
            The (S,G) source list entry is used in Join/Prune messages
            sent towards the specified source.  It expresses interest
            (or lack thereof) in receiving traffic through the shortest
            path tree sent by the source to the specified group.  For
            each source address, the entry MUST exist in only one of the
            Joined and Pruned source lists of a group-specific set, but
            not both.

            (S,G) source list entries have the Source-Address set to the
            address of the source S, the Source-Address Mask-Len set to
            the full length of the IP address, and both the WC and RPT
            bits of the encoded source address cleared.

   The rules described above are sufficient to prevent invalid
   combinations of source list entries in group-specific sets.  There
   are, however, a number of combinations that have a valid
   interpretation but that are not generated by the protocol as
   described in this specification:

   o  Combining a (*,G) Join and an (S,G,rpt) Join entry in the same
      message is redundant, as the (*,G) entry covers the information
      provided by the (S,G,rpt) entry.

   o  The same applies for a (*,G) Prune and an (S,G,rpt) Prune.

   o  The combination of a (*,G) Prune and an (S,G,rpt) Join is also not
      generated.  (S,G,rpt) Joins are only sent when the router is
      receiving all traffic for a group on the shared tree and it wishes
      to indicate a change for the particular source.  As a (*,G) prune
      indicates that the router no longer wishes to receive shared tree
      traffic, the (S,G,rpt) Join would be meaningless.





Fenner, et al.               Standards Track                  [Page 118]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   o  As Join/Prune messages are targeted to a single PIM neighbor,
      including both an (S,G) Join and an (S,G,rpt) Prune in the same
      message is usually redundant.  The (S,G) Join informs the neighbor
      that the sender wishes to receive the particular source on the
      shortest path tree.  It is therefore unnecessary for the router to
      say that it no longer wishes to receive it on the shared tree.
      However, there is a valid interpretation for this combination of
      entries.  A downstream router may have to instruct its upstream
      only to start forwarding a specific source once it has started
      receiving the source on the shortest-path tree.

   o  The combination of an (S,G) Prune and an (S,G,rpt) Join could
      possibly be used by a router to switch from receiving a particular
      source on the shortest-path tree back to receiving it on the
      shared tree (provided that the RPF neighbor for the shortest-path
      and shared trees is common).  However, Sparse-Mode PIM does not
      provide a mechanism for explicitly switching back to the shared
      tree.

   The rules are summarized in the table below.

   +----------++------+-------+-----------+-----------+-------+-------+
   |          ||Join  | Prune | Join      | Prune     | Join  | Prune |
   |          ||(*,G) | (*,G) | (S,G,rpt) | (S,G,rpt) | (S,G) | (S,G) |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||-     | no    | ?         | yes       | yes   | yes   |
   |(*,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||no    | -     | ?         | ?         | yes   | yes   |
   |(*,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||?     | ?     | -         | no        | yes   | ?     |
   |(S,G,rpt) ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||yes   | ?     | no        | -         | yes   | ?     |
   |(S,G,rpt) ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Join      ||yes   | yes   | yes       | yes       | -     | no    |
   |(S,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+
   |Prune     ||yes   | yes   | ?         | ?         | no    | -     |
   |(S,G)     ||      |       |           |           |       |       |
   +----------++------+-------+-----------+-----------+-------+-------+








Fenner, et al.               Standards Track                  [Page 119]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   yes   Allowed and expected.

   no    Combination is not allowed by the protocol and MUST NOT be
         generated by a router.  A router MAY accept these messages, but
         the result is undefined.  An error message MAY be logged to the
         administrator in a rate-limited manner.

   ?     Combination not expected by the protocol, but well defined.  A
         router MAY accept it but SHOULD NOT generate it.

   The order of source list entries in a group set source list is not
   important, except where limited by the packet format itself.

4.9.5.2.  Group Set Fragmentation

   When building a Join/Prune for a particular neighbor, a router should
   try to include in the message as much of the information it needs to
   convey to the neighbor as possible.  This implies adding one group
   set for each multicast group that has information pending
   transmission and within each set including all relevant source list
   entries.

   On a router with a large amount of multicast state, the number of
   entries that must be included may result in packets that are larger
   than the maximum IP packet size.  In most such cases, the information
   may be split into multiple messages.

   There is an exception with group sets that contain a (*,G) Joined
   source list entry.  The group set expresses the router's interest in
   receiving all traffic for the specified group on the shared tree, and
   it MUST include an (S,G,rpt) Pruned source list entry for every
   source that the router does not wish to receive.  This list of
   (S,G,rpt) Pruned source list entries MUST NOT be split in multiple
   messages.

   If only N (S,G,rpt) Prune entries fit into a maximum-sized Join/Prune
   message, but the router has more than N (S,G,rpt) Prunes to add, then
   the router MUST choose to include the first N (numerically smallest
   in network byte order) IP addresses, and the rest are ignored (not
   included).











Fenner, et al.               Standards Track                  [Page 120]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.9.6.  Assert Message Format

   The Assert message is used to resolve forwarder conflicts between
   routers on a link.  It is sent when a router receives a multicast
   data packet on an interface on which the router would normally have
   forwarded that packet.  Assert messages may also be sent in response
   to an Assert message from another router.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |   Reserved    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Group Address (Encoded-Group format)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source Address (Encoded-Unicast format)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|                      Metric Preference                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Metric                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PIM Version, Type, Reserved, Checksum
         Described in Section 4.9.

   Group Address
         The group address for which the router wishes to resolve the
         forwarding conflict.  This is an encoded group address, as
         specified in Section 4.9.1.

   Source Address
         Source address for which the router wishes to resolve the
         forwarding conflict.  The source address MAY be set to zero for
         (*,G) asserts (see below).  The format for this address is
         given in the encoded unicast address in Section 4.9.1.

   R     RPTbit is a 1-bit value.  The RPTbit is set to 1 for
         Assert(*,G) messages and 0 for Assert(S,G) messages.

   Metric Preference
         Preference value assigned to the unicast routing protocol that
         provided the route to the multicast source or Rendezvous Point.

   Metric
         The unicast routing table metric associated with the route used
         to reach the multicast source or Rendezvous Point.  The metric
         is in units applicable to the unicast routing protocol used.




Fenner, et al.               Standards Track                  [Page 121]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Assert messages can be sent to resolve a forwarding conflict for all
   traffic to a given group or for a specific source and group.

   Assert(S,G)
         Source-specific asserts are sent by routers forwarding a
         specific source on the shortest-path tree (SPTbit is TRUE).
         (S,G) Asserts have the Group-Address field set to the group G
         and the Source-Address field set to the source S.  The RPTbit
         is set to 0, the Metric-Preference is set to MRIB.pref(S), and
         the Metric is set to MRIB.metric(S).

   Assert(*,G)
         Group-specific asserts are sent by routers forwarding data for
         the group and source(s) under contention on the shared tree.
         (*,G) asserts have the Group-Address field set to the group G.
         For data-triggered Asserts, the Source-Address field MAY be set
         to the IP source address of the data packet that triggered the
         Assert and is set to zero otherwise.  The RPTbit is set to 1,
         the Metric-Preference is set to MRIB.pref(RP(G)), and the
         Metric is set to MRIB.metric(RP(G)).

4.10.  PIM Timers

   PIM-SM maintains the following timers, as discussed in Section 4.11.
   All timers are countdown timers; they are set to a value and count
   down to zero, at which point they typically trigger an action.  Of
   course, they can just as easily be implemented as count-up timers,
   where the absolute expiry time is stored and compared against a
   real-time clock, but the language in this specification assumes that
   they count downwards to zero.





















Fenner, et al.               Standards Track                  [Page 122]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Global Timers

   Per interface (I):

        Hello Timer: HT(I)

        Per neighbor (N):

             Neighbor Liveness Timer: NLT(N,I)

        Per Group (G):

             (*,G) Join Expiry Timer: ET(*,G,I)

             (*,G) Prune-Pending Timer: PPT(*,G,I)

             (*,G) Assert Timer: AT(*,G,I)

             Per Source (S):

                  (S,G) Join Expiry Timer: ET(S,G,I)

                  (S,G) Prune-Pending Timer: PPT(S,G,I)

                  (S,G) Assert Timer: AT(S,G,I)

                  (S,G,rpt) Prune Expiry Timer: ET(S,G,rpt,I)

                  (S,G,rpt) Prune-Pending Timer: PPT(S,G,rpt,I)

   Per Group (G):

        (*,G) Upstream Join Timer: JT(*,G)

        Per Source (S):

             (S,G) Upstream Join Timer: JT(S,G)

             (S,G) Keepalive Timer: KAT(S,G)

             (S,G,rpt) Upstream Override Timer: OT(S,G,rpt)

   At the DRs or relevant Assert Winners only:

        Per Source,Group pair (S,G):

             Register-Stop Timer: RST(S,G)




Fenner, et al.               Standards Track                  [Page 123]

RFC 7761             PIM-SM Specification (Revised)           March 2016


4.11.  Timer Values

   When timers are started or restarted, they are set to default values.
   This section summarizes those default values.

   Note that protocol events or configuration may change the default
   value of a timer on a specific interface.  When timers are
   initialized in this document, the value specific to the interface in
   context must be used.

   Some of the timers listed below (Prune-Pending, Upstream Join,
   Upstream Override) can be set to values that depend on the settings
   of the Propagation_Delay and Override_Interval of the corresponding
   interface.  The default values for these are given below.

   Variable Name: Propagation_Delay(I)

+-------------------------------+--------------+----------------------+
|  Value Name                   |  Value       |  Explanation         |
+-------------------------------+--------------+----------------------+
|  Propagation_delay_default    |  0.5 secs    |  Expected            |
|                               |              |  propagation delay   |
|                               |              |  over the local      |
|                               |              |  link.               |
+-------------------------------+--------------+----------------------+

   The default value of the Propagation_delay_default is chosen to be
   relatively large to provide compatibility with older PIM
   implementations.

   Variable Name: Override_Interval(I)

+--------------------------+-----------------+-------------------------+
|  Value Name              |    Value        |    Explanation          |
+--------------------------+-----------------+-------------------------+
|  t_override_default      |    2.5 secs     |    Default delay        |
|                          |                 |    interval over        |
|                          |                 |    which to randomize   |
|                          |                 |    when scheduling a    |
|                          |                 |    delayed Join         |
|                          |                 |    message.             |
+--------------------------+-----------------+-------------------------+









Fenner, et al.               Standards Track                  [Page 124]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Timer Name: Hello Timer (HT(I))

+---------------------+--------+---------------------------------------+
|Value Name           | Value  | Explanation                           |
+---------------------+--------+---------------------------------------+
|Hello_Period         | 30 secs| Periodic interval for Hello messages. |
+---------------------+--------+---------------------------------------+
|Triggered_Hello_Delay| 5 secs | Randomized interval for initial Hello |
|                     |        | message on bootup or triggered Hello  |
|                     |        | message to a rebooting neighbor.      |
+---------------------+--------+---------------------------------------+

   At system power-up, the timer is initialized to
   rand(0, Triggered_Hello_Delay) to prevent synchronization.  When a
   new or rebooting neighbor is detected, a responding Hello is sent
   within rand(0, Triggered_Hello_Delay).

   Timer Name: Neighbor Liveness Timer (NLT(N,I))

+--------------------------+----------------------+--------------------+
| Value Name               |  Value               |  Explanation       |
+--------------------------+----------------------+--------------------+
| Default_Hello_Holdtime   |  3.5 * Hello_Period  |  Default holdtime  |
|                          |                      |  to keep neighbor  |
|                          |                      |  state alive       |
+--------------------------+----------------------+--------------------+
| Hello_Holdtime           |  from message        |  Holdtime from     |
|                          |                      |  Hello message     |
|                          |                      |  Holdtime option.  |
+--------------------------+----------------------+--------------------+

   The Holdtime in a Hello message should be set to
   (3.5 * Hello_Period), giving a default value of 105 seconds.

   Timer Names: Expiry Timer (ET(*,G,I), ET(S,G,I), ET(S,G,rpt,I))

+----------------+----------------+------------------------------------+
| Value Name     |  Value         |  Explanation                       |
+----------------+----------------+------------------------------------+
| J/P_HoldTime   |  from message  |  Holdtime from Join/Prune message  |
+----------------+----------------+------------------------------------+

   The value of J/P Holdtime that is included in Join/Prune messages is
   specified below, in the description of "Upstream Join Timer (JT(*,G),
   JT(S,G))".






Fenner, et al.               Standards Track                  [Page 125]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Timer Names: Prune-Pending Timer (PPT(*,G,I), PPT(S,G,I),
   PPT(S,G,rpt,I))

+--------------------------+---------------------+---------------------+
|Value Name                | Value               | Explanation         |
+--------------------------+---------------------+---------------------+
|J/P_Override_Interval(I)  | Default:            | Short period after  |
|                          | Effective_          | a join or prune to  |
|                          | Propagation_        | allow other         |
|                          | Delay(I) +          | routers on the LAN  |
|                          | Effective_Override_ | to override the     |
|                          | Interval(I)         | join or prune       |
+--------------------------+---------------------+---------------------+

   Note that both Effective_Propagation_Delay(I) and
   Effective_Override_Interval(I) are interface-specific values that may
   change when Hello messages are received (see Section 4.3.3).

   Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I))

+---------------------------+---------------------+--------------------+
| Value Name                | Value               | Explanation        |
+---------------------------+---------------------+--------------------+
| Assert_Override_Interval  | Default: 3 secs     | Short interval     |
|                           |                     | before an assert   |
|                           |                     | times out where    |
|                           |                     | the assert winner  |
|                           |                     | resends an Assert  |
|                           |                     | message            |
+---------------------------+---------------------+--------------------+
| Assert_Time               | Default: 180 secs   | Period after last  |
|                           |                     | assert before      |
|                           |                     | assert state is    |
|                           |                     | timed out          |
+---------------------------+---------------------+--------------------+

   Note that for historical reasons, the Assert message lacks a Holdtime
   field.  Thus, changing the Assert Time from the default value is not
   recommended.












Fenner, et al.               Standards Track                  [Page 126]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Timer Names: Upstream Join Timer (JT(*,G), JT(S,G))

+-------------+--------------------+-----------------------------------+
|Value Name   | Value              | Explanation                       |
+-------------+--------------------+-----------------------------------+
|t_periodic   | Default: 60 secs   | Period between Join/Prune messages|
+-------------+--------------------+-----------------------------------+
|t_suppressed | rand(1.1 *         | Suppression period when someone   |
|             | t_periodic, 1.4 *  | else sends a J/P message so we    |
|             | t_periodic) when   | don't need to do so.              |
|             | Suppression_       |                                   |
|             | Enabled(I) is      |                                   |
|             | true, 0 otherwise  |                                   |
+-------------+--------------------+-----------------------------------+
|t_override   | rand(0, Effective_ | Randomized delay to prevent       |
|             | Override_          | response implosion when sending a |
|             | Interval(I))       | Join message to override someone  |
|             |                    | else's Prune message.             |
+-------------+--------------------+-----------------------------------+

   t_periodic may be set to take into account such things as the
   configured bandwidth and expected average number of multicast route
   entries for the attached network or link (e.g., the period would be
   longer for lower-speed links, or for routers in the center of the
   network that expect to have a larger number of entries).  If the
   Join/Prune-Period is modified during operation, these changes should
   be made relatively infrequently, and the router should continue to
   refresh at its previous Join/Prune-Period for at least
   Join/Prune-Holdtime, in order to allow the upstream router to adapt.

   The Holdtime specified in a Join/Prune message should be set to
   (3.5 * t_periodic).

   t_override depends on the Effective Override Interval of the upstream
   interface, which may change when Hello messages are received.

   t_suppressed depends on the Suppression State of the upstream
   interface (Section 4.3.3) and becomes zero when suppression is
   disabled.












Fenner, et al.               Standards Track                  [Page 127]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Timer Name: Upstream Override Timer (OT(S,G,rpt))

+---------------+--------------------------+---------------------------+
| Value Name    | Value                    |  Explanation              |
+---------------+--------------------------+---------------------------+
| t_override    | see Upstream Join Timer  |  see Upstream Join Timer  |
+---------------+--------------------------+---------------------------+

   The Upstream Override Timer is only ever set to the t_override value;
   this value is defined earlier in this section, under "Timer Names:
   Upstream Join Timer (JT(*,G), JT(S,G))".

   Timer Name: Keepalive Timer (KAT(S,G))

+-----------------------+-----------------------+----------------------+
| Value Name            |  Value                |  Explanation         |
+-----------------------+-----------------------+----------------------+
| Keepalive_Period      |  Default: 210 secs    |  Period after last   |
|                       |                       |  (S,G) data packet   |
|                       |                       |  during which (S,G)  |
|                       |                       |  Join state will be  |
|                       |                       |  maintained even in  |
|                       |                       |  the absence of      |
|                       |                       |  (S,G) Join          |
|                       |                       |  messages.           |
+-----------------------+-----------------------+----------------------+
| RP_Keepalive_Period   |  ( 3 * Register_      |  As                  |
|                       |  Suppression_Time )   |  Keepalive_Period,   |
|                       |  + Register_          |  but at the RP when  |
|                       |  Probe_Time           |  a Register-Stop is  |
|                       |                       |  sent.               |
+-----------------------+-----------------------+----------------------+

   The normal keepalive period for the KAT(S,G) defaults to 210 seconds.
   However, at the RP, the keepalive period must be at least the
   Register_Suppression_Time, or the RP may time out the (S,G) state
   before the next Null-Register arrives.  Thus, the KAT(S,G) is set to
   max(Keepalive_Period, RP_Keepalive_Period) when a Register-Stop
   is sent.












Fenner, et al.               Standards Track                  [Page 128]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Timer Name: Register-Stop Timer (RST(S,G))

+---------------------------+--------------------+---------------------+
|Value Name                 | Value              | Explanation         |
+---------------------------+--------------------+---------------------+
|Register_Suppression_Time  | Default: 60 secs   | Period during       |
|                           |                    | which a DR stops    |
|                           |                    | sending Register-   |
|                           |                    | encapsulated data   |
|                           |                    | to the RP after     |
|                           |                    | receiving a         |
|                           |                    | Register-Stop       |
|                           |                    | message.            |
+---------------------------+--------------------+---------------------+
|Register_Probe_Time        | Default: 5 secs    | Time before RST     |
|                           |                    | expires when a DR   |
|                           |                    | may send a Null-    |
|                           |                    | Register to the RP  |
|                           |                    | to cause it to      |
|                           |                    | resend a Register-  |
|                           |                    | Stop message.       |
+---------------------------+--------------------+---------------------+

   If the Register_Suppression_Time or the Register_Probe_Time is
   configured to values other than the defaults, it MUST be ensured that
   the value of the Register_Probe_Time is less than half the value of
   the Register_Suppression_Time to prevent a possible negative value in
   the setting of the Register-Stop Timer.























Fenner, et al.               Standards Track                  [Page 129]

RFC 7761             PIM-SM Specification (Revised)           March 2016


5.  IANA Considerations

5.1.  PIM Address Family

   The PIM Address Family field was chosen to be 8 bits as a tradeoff
   between packet format and use of the IANA-assigned numbers.  Because
   when the PIM packet format was designed only 15 values were assigned
   for Address Families, and large numbers of new Address Family values
   were not envisioned, 8 bits seemed large enough.  However, the IANA
   assigns Address Families in a 16-bit field.  Therefore, the PIM
   Address Family is allocated as follows:

      Values 0 through 127 are designated to have the same meaning as
      IANA-assigned Address Family Numbers [7].

      Values 128 through 250 are designated to be assigned for PIM by
      the IANA based upon IESG Approval, as defined in [9].

      Values 251 through 255 are designated for Private Use, as defined
      in [9].

5.2.  PIM Hello Options

   Values 17 through 65000 are to be assigned by the IANA.  Since the
   space is large, they may be assigned as First Come First Served, as
   defined in [9].  Such assignments are valid for one year and may be
   renewed.  Permanent assignments require a specification (see
   "Specification Required" in [9]).























Fenner, et al.               Standards Track                  [Page 130]

RFC 7761             PIM-SM Specification (Revised)           March 2016


6.  Security Considerations

   This section describes various possible security concerns related to
   the PIM-SM protocol.  The reader is referred to [8], [14], and [15]
   for further discussion of PIM-SM and multicast security.

   Note that PIM relies upon an MRIB populated outside of PIM;
   therefore, securing the sources of change to the MRIB is RECOMMENDED.

6.1.  Attacks Based on Forged Messages

   The extent of possible damage depends on the type of counterfeit
   messages accepted.  We next consider the impact of possible
   forgeries, including forged link-local (Join/Prune, Hello, and
   Assert) and forged unicast (Register and Register-Stop) messages.

6.1.1.  Forged Link-Local Messages

   Join/Prune, Hello, and Assert messages are all sent to the link-local
   ALL-PIM-ROUTERS multicast address and thus are not forwarded by a
   compliant router.  A forged message of this type can only reach a LAN
   if it was sent by a local host or if it was allowed onto the LAN by a
   compromised or non-compliant router.

   1.  A forged Join/Prune message can cause multicast traffic to be
       delivered to links where there are no legitimate requesters,
       potentially wasting bandwidth on that link.  A forged leave
       message on a multi-access LAN is generally not a significant
       attack in PIM, because any legitimately joined router on the LAN
       would override the leave with a join before the upstream router
       stops forwarding data to the LAN.

   2.  By forging a Hello message, an unauthorized router can cause
       itself to be elected as the Designated Router on a LAN.  The
       Designated Router on a LAN is (in the absence of asserts)
       responsible for forwarding traffic to that LAN on behalf of any
       local members.  The Designated Router is also responsible for
       register-encapsulating to the RP any packets that are originated
       by hosts on the LAN.  Thus, the ability of local hosts to send
       and receive multicast traffic may be compromised by a forged
       Hello message.

   3.  By forging an Assert message on a multi-access LAN, an attacker
       could cause the legitimate designated forwarder to stop
       forwarding traffic to the LAN.  Such a forgery would prevent any
       hosts downstream of that LAN from receiving traffic.





Fenner, et al.               Standards Track                  [Page 131]

RFC 7761             PIM-SM Specification (Revised)           March 2016


6.1.2.  Forged Unicast Messages

   Register messages and Register-Stop messages are forwarded by
   intermediate routers to their destination using normal IP forwarding.
   Without data origin authentication, an attacker who is located
   anywhere in the network may be able to forge a Register or
   Register-Stop message.  We next consider the effect of a forgery of
   each of these messages.

   1.  By forging a Register message, an attacker can cause the RP to
       inject forged traffic onto the shared multicast tree.

   2.  By forging a Register-Stop message, an attacker can prevent a
       legitimate DR from registering packets to the RP.  This can
       prevent local hosts on that LAN from sending multicast packets.

   The above two PIM messages are not changed by intermediate routers
   and need only be examined by the intended receiver.  Thus, these
   messages can be authenticated end-to-end.  Attacks on Register and
   Register-Stop messages do not apply to a PIM-SSM-only implementation,
   as these messages are not required for PIM-SSM.

6.2.  Non-cryptographic Authentication Mechanisms

   A PIM router SHOULD provide an option to limit the set of neighbors
   from which it will accept Join/Prune, Assert, and Hello messages.
   Either static configuration of IP addresses or an IPsec security
   association MAY be used.  Furthermore, a PIM router SHOULD NOT accept
   protocol messages from a router from which it has not yet received a
   valid Hello message.

   A Designated Router MUST NOT register-encapsulate a packet and send
   it to the RP unless the source address of the packet is a legal
   address for the subnet on which the packet was received.  Similarly,
   a Designated Router SHOULD NOT accept a Register-Stop packet whose IP
   source address is not a valid RP address for the local domain.

   An implementation SHOULD provide a mechanism to allow an RP to
   restrict the range of source addresses from which it accepts
   Register-encapsulated packets.

   All options that restrict the range of addresses from which packets
   are accepted MUST default to allowing all packets.








Fenner, et al.               Standards Track                  [Page 132]

RFC 7761             PIM-SM Specification (Revised)           March 2016


6.3.  Authentication

   This document refers to RFC 5796 [8], which specifies mechanisms to
   authenticate PIM-SM link-local messages using the IPsec Encapsulating
   Security Payload (ESP) or (optionally) the Authentication Header
   (AH).  It also points out that non-link-local PIM-SM messages (i.e.,
   Register and Register-Stop messages) can be secured by a normal
   unicast IPsec Security Association (SA) between two communicants.

6.4.  Denial-of-Service Attacks

   There are a number of possible denial-of-service attacks against PIM
   that can be caused by generating false PIM protocol messages or even
   by generating false traffic.  Authenticating PIM protocol traffic
   prevents some, but not all, of these attacks.  Two of the possible
   attacks include the following:

   o  Sending packets to many different group addresses quickly can be a
      denial-of-service attack in and of itself.  This will cause many
      register-encapsulated packets, loading the DR, the RP, and the
      routers between the DR and the RP.

   o  Forging Join messages can cause a multicast tree to get set up.
      A large number of forged joins can consume router resources and
      result in denial of service.

7.  References

7.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
        <http://www.rfc-editor.org/info/rfc2119>.

   [2]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
        Thyagarajan, "Internet Group Management Protocol, Version 3",
        RFC 3376, DOI 10.17487/RFC3376, October 2002,
        <http://www.rfc-editor.org/info/rfc3376>.

   [3]  Deering, S., "Host extensions for IP multicasting", STD 5,
        RFC 1112, DOI 10.17487/RFC1112, August 1989,
        <http://www.rfc-editor.org/info/rfc1112>.

   [4]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
        Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710,
        October 1999, <http://www.rfc-editor.org/info/rfc2710>.





Fenner, et al.               Standards Track                  [Page 133]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,
        <http://www.rfc-editor.org/info/rfc2460>.

   [6]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
        RFC 4607, DOI 10.17487/RFC4607, August 2006,
        <http://www.rfc-editor.org/info/rfc4607>.

   [7]  IANA, "Address Family Numbers",
        <http://www.iana.org/assignments/address-family-numbers>.

   [8]  Atwood, W., Islam, S., and M. Siami, "Authentication and
        Confidentiality in Protocol Independent Multicast Sparse Mode
        (PIM-SM) Link-Local Messages", RFC 5796, DOI 10.17487/RFC5796,
        March 2010, <http://www.rfc-editor.org/info/rfc5796>.

   [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 5226,
        DOI 10.17487/RFC5226, May 2008,
        <http://www.rfc-editor.org/info/rfc5226>.

7.2.  Informative References

   [10] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
        Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760,
        January 2007, <http://www.rfc-editor.org/info/rfc4760>.

   [11] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
        Router (BSR) Mechanism for Protocol Independent Multicast
        (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008,
        <http://www.rfc-editor.org/info/rfc5059>.

   [12] Black, D., "Differentiated Services and Tunnels", RFC 2983,
        DOI 10.17487/RFC2983, October 2000,
        <http://www.rfc-editor.org/info/rfc2983>.

   [13] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
        "Bidirectional Protocol Independent Multicast (BIDIR-PIM)",
        RFC 5015, DOI 10.17487/RFC5015, October 2007,
        <http://www.rfc-editor.org/info/rfc5015>.

   [14] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent
        Multicast - Sparse Mode (PIM-SM) Multicast Routing Security
        Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609,
        October 2006, <http://www.rfc-editor.org/info/rfc4609>.






Fenner, et al.               Standards Track                  [Page 134]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   [15] Savola, P. and J. Lingard, "Host Threats to Protocol Independent
        Multicast (PIM)", RFC 5294, DOI 10.17487/RFC5294, August 2008,
        <http://www.rfc-editor.org/info/rfc5294>.

   [16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP)
        Address in an IPv6 Multicast Address", RFC 3956,
        DOI 10.17487/RFC3956, November 2004,
        <http://www.rfc-editor.org/info/rfc3956>.

   [17] Zheng, L., Zhang, J., and R. Parekh, "Survey Report on Protocol
        Independent Multicast - Sparse Mode (PIM-SM) Implementations and
        Deployments", RFC 7063, DOI 10.17487/RFC7063, December 2013,
        <http://www.rfc-editor.org/info/rfc7063>.






































Fenner, et al.               Standards Track                  [Page 135]

RFC 7761             PIM-SM Specification (Revised)           March 2016


Appendix A.  Functionality Removed from RFC 4601

   Based on a survey of PIM implementations and deployments [17]
   conducted by the IETF PIM working group, the following functionality
   of RFC 4601 has been removed due to lack of sufficient implementation
   and deployment experience:

   o  (*,*,RP) State

   o  PIM Multicast Border Router (PMBR)

   o  Authentication using IPsec

Acknowledgements

   PIM-SM was designed over many years by a large group of people,
   including ideas, comments, and corrections from Deborah Estrin, Dino
   Farinacci, Ahmed Helmy, David Thaler, Steve Deering, Van Jacobson, C.
   Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Tony Ballardie, Scott
   Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Horst Hodel, Polly
   Huang, Stephen Ostrowski, Lixia Zhang, Girish Chandranmenon, Brian
   Haberman, Hal Sandick, Mike Mroz, Garry Kump, Pavlin Radoslavov, Mike
   Davison, James Huang, Christopher Thomas Brown, and James Lingard.

   Thanks are due to the American Licorice Company, for its obscure but
   possibly essential role in the creation of this document.

Authors' Addresses

   Bill Fenner
   Arista Networks

   Email: fenner@arista.com


   Mark Handley
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   United Kingdom

   Email: M.Handley@cs.ucl.ac.uk








Fenner, et al.               Standards Track                  [Page 136]

RFC 7761             PIM-SM Specification (Revised)           March 2016


   Hugh Holbrook
   Arista Networks
   5453 Great America Parkway
   Santa Clara, CA  95054

   Email: holbrook@arista.com


   Isidor Kouvelas
   Arista Networks
   5453 Great America Parkway
   Santa Clara, CA  95054

   Email: kouvelas@arista.com


   Rishabh Parekh
   Cisco Systems, Inc.
   170 W. Tasman Drive
   San Jose, CA  95134

   Email: riparekh@cisco.com


   Zhaohui Zhang
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886

   Email: zzhang@juniper.net


   Lianshu Zheng
   Huawei Technologies Co., Ltd
   Huawei Campus, 156 Beiqing Road, Hai-dian District
   Beijing  100089
   China

   Email: vero.zheng@huawei.com












Fenner, et al.               Standards Track                  [Page 137]