RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 14 records.

Status: Verified (2)

RFC 4301, "Security Architecture for the Internet Protocol", December 2005

Note: This RFC has been updated by RFC 6040, RFC 7619

Source of RFC: ipsec (sec)

Errata ID: 2180
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section 4.4.2.2. says:

OPAQUE****        0  prot. "P"    OPAQUE

It should say:

OPAQUE****        0  prot. "P"    discard packet

Notes:

Opaque means protocol must not be available. Therefore this packet does not match and must be discarded.
The same four times more.

Errata ID: 2184
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20

Section D2 says:

We could define ANY as the complement of OPAQUE,
i.e., it would match all values but only for accessible port fields.

It should say:

We could define ANY as the complement of OPAQUE,
i.e., it would match all values but only for accessible port fields.
But we did not. ANY encompasses OPAQUE.

Notes:

misleading

Status: Held for Document Update (7)

RFC 4301, "Security Architecture for the Internet Protocol", December 2005

Note: This RFC has been updated by RFC 6040, RFC 7619

Source of RFC: ipsec (sec)

Errata ID: 135
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2008-12-04

Appendix A2 says:

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE -- included in ICV calculation
         Routing (Type 0)                    [DH98]

       BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
       TRANSIT)
         Hop-by-Hop options                  [DH98]
         Destination options                 [DH98]

       NOT APPLICABLE
         Fragmentation                       [DH98]

It should say:

       Option/Extension Name                  Reference
       -----------------------------------    ---------
       MUTABLE BUT PREDICTABLE
       -- included in ICV calculation
         Routing (Type 0)                       [DH98]

       BIT INDICATES IF OPTION IS MUTABLE
       (CHANGES UNPREDICTABLY DURING TRANSIT)
         Hop-by-Hop options                     [DH98]
         Destination options                    [DH98]

       NOT APPLICABLE
         Fragmentation                          [DH98]

Notes:

Perhaps it should be formatted as shown above to avoid the overlap of the columns.

Errata ID: 717
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2010-03-11

 

(1)  [typo]

In section 4.1, on page 14, RFC 4301 says:

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
   as that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

It should say ( s/in used/is used/ ) :

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
|  as that term is used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

(2)  [textual improvement]

In section 4.4.3.2, the last lines on page 45 say:

                                                      [...].  An entry
   used with certificate-based authentication MAY include additional
   data to facilitate certificate revocation status, e.g., a list of
 << page break >>
   appropriate OCSP responders or CRL repositories, [...]

This seems to make not much sense. It should perhaps say:

                                                      [...].  An entry
   used with certificate-based authentication MAY include additional
   data to facilitate certificate revocation status determination, e.g.,
   a list of appropriate OCSP responders or CRL repositories, [...]

(3)  [typo]

The second paragraph of section 4.4.3.3, on page 46, says:

   If the entry indicates that the IKE ID is to be used, then the PAD
   entry ID field defines the authorized set of IDs.  If the entry
   indicates that child SAs traffic selectors are to be used, then an
   additional data element is required, in the form of IPv4 and/or IPv6
   address ranges. [...]

It should say ( s/SAa/SA/ ) :

   If the entry indicates that the IKE ID is to be used, then the PAD
   entry ID field defines the authorized set of IDs.  If the entry
|  indicates that child SA traffic selectors are to be used, then an
   additional data element is required, in the form of IPv4 and/or IPv6
   address ranges. [...]

(4)  [textual consistency]

Below the table on page 59, section 5.1.2.2 says:

    Notes:

      (1) - (6) See Section 5.1.2.1.

It should say:

    Notes:

|     (1) - (3), (5), (6)  See Section 5.1.2.1.


(5)  [typo]

The second paragraph of App. D.2, on page 89, says:

                                                    [...]. (If we choose
   to allow carriage of fragments on transport mode SAs for IPv6, the
   problems arises in that context as well.)
          ^     ^^

There obviously is a singular/plural mismatch.
The text should say:
                                                    [...]. (If we choose
   to allow carriage of fragments on transport mode SAs for IPv6, the
|  problem arises in that context as well.)


(6)  Insufficient IPcomp integration

At the end of section 3.1, on page 10, RFC 4301 says:

   IPsec optionally supports negotiation of IP compression [SMPT01],
   motivated in part by the observation that when encryption is employed
   within IPsec, it prevents effective compression by lower protocol
   layers.

It has also been observed that payload compression can help counter
TPA.  Thus, there are at least two reasons for a tight integration
of IPComp with IPsec.
But I could not find any 'hook' in RFC 4301 (and in RFC 4302 / 4303
as well) for the concrete support of IPComp in ESP / AH IPsec SAs.

IKEv2 (RFC 4306) roughly allows negotiation of IPComp, but how shall
that be triggered and work, in an interoperable way, if there are no
architectural provisions for the support of IPComp designed in into
the IPsec databases (SPD, SAD) as described in RFC 4301 ????


(7)  Insufficient integration with QoS (DS)

The steps taken for the integration with Differentiated Services
are half-hearted.  The processing rules specified for the DSCP
field in the IP header[s] remain incomplete as long as there is
no specified interoperable way to use DSCP as an selector as well.

IMHO, the discussion on page 14 of RFC 4301 is misleading because
DS classification and treatment needs to be done independent from
IPsec treatment.
In many scenarios, e.g. on 'hosts' or 'QoS gateways' that must
perform fine-grained traffic classification, DS treatment must
be performed strictly before IPsec treatment in the outbound
case (and after IPsec in the inbound case), to make ULP fields
accessible to the DS classifiers.
IPsec should then be capable of guaranteeing the same security
treatment of all packets of certain traffic class to a given
destination.

I still have problems to imagine how DS integration could be
achieved with the processing model of section 5.1 of RFC 4301.

At the end of section 3.1, on page 10, RFC 4301 says:


(8)  Inconsistent DS Field handling specified in Section 5.1.2.x

The IPv6 related table in section 5.1.2.2 contains the line,

        DS Field         copied from inner hdr (5)    no change (9)

and the subsequent Notes give a lengthy explanation under (9).

Contrary to that, the corresponding table line for IPv4, in section
5.1.2.1 on page 57, is *not* linked to such a note.

I cannot see any reason precluding the application of the arguments
given in Note (9) of section 5.1.2.2 to the IPv4 case as well.

Have I missed any significant point there?


(9)  SA negotiation -- capability mismatch with IKEv2

See section 4.4.1.2, second paragraph.

It should say:

[see above]

Notes:

from pending

Errata ID: 1684
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2009-02-17
Held for Document Update by: Pasi Eronen

Section 4.5.3. says:

   Consider a situation in which a remote host (SH1) is using the
   Internet to gain access to a server or other machine (H2) and there
   is a security gateway (SG2), e.g., a firewall, through which H1's
   traffic must pass.

It should say:

   Consider a situation in which a remote host (SH1) is using the
   Internet to gain access to a server or other machine (H2) and there
   is a security gateway (SG2), e.g., a firewall, through which SH1's
   traffic must pass.

Errata ID: 1713
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2009-03-12
Held for Document Update by: Pasi Eronen

Section 12 says:

   The IANA has assigned the value (3) for the asn1-modules registry and
   has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD
   module.  See Appendix C, "ASN.1 for an SPD Entry".

It should say:

   The IANA has assigned the value (3) for the asn1-modules registry and
   has assigned the object identifier 1.3.6.1.5.5.8.3.1 for the SPD
   module.  See Appendix C, "ASN.1 for an SPD Entry".

Notes:

See http://www.iana.org/assignments/smi-numbers

Errata ID: 2179
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 4.4.2.2 says:

list of prot's

It should say:

list of prots

Notes:

This is not genitive. It's plural.

Errata ID: 2181
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk

Section 4.4.3.1. says:

The Key ID field is defined as an OCTET string in IKE.  For this name
type, only exact-match syntax MUST be supported (since there is no
explicit structure for this ID type).  Additional matching functions
MAY be supported for this ID type.

It should say:

The Key ID field is defined as an OCTET string in IKE.  For this name
type, exact-match syntax MUST be supported (since there is no
explicit structure for this ID type).  Additional matching functions
MAY be supported for this ID type.

Notes:

'only A must be supported' is ambigous.
Does it mean 'A must be supportet and anything else must not be supportet', or does it mean 'A must be supportet and anything else may be supportet'. The next sentence clearifies that it is the second interpretation.

Errata ID: 2182
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk

Section 4.4.3.2 says:

This document requires support for two required authentication data
types:

It should say:

This document requires support for two authentication data
types:

Notes:

pleonasm

Status: Rejected (5)

RFC 4301, "Security Architecture for the Internet Protocol", December 2005

Note: This RFC has been updated by RFC 6040, RFC 7619

Source of RFC: ipsec (sec)

Errata ID: 2178
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20

Section 4.1.1. says:

SPD-S, SPD-I, SPD-O
Pages 20,21

It should say:

Needs to be formulated differently.

Notes:

This text needs information which comes later in RFC4301. There must be an explanation of decorrelation (hint on Appendix B).
The part of outbound traffic is confusing. If you have no SPD-S entries, you can handle it the same way as explained for inbound traffic.
--VERIFIER NOTES--
There is no section 4.1.1.

Errata ID: 6635
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Isaac Lewis
Date Reported: 2021-07-09
Rejected by: Benjamin Kaduk
Date Rejected: 2021-07-21

Section 3.2 says:

Note that ESP can be used to provide only integrity, without
confidentiality, making it comparable to AH in most contexts.

It should say:

Note that ESP can be used to provide both integrity and
confidentiality.

Notes:

The original sentence contradicts the following one in the same section:

o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
the same set of services, and also offers confidentiality.
--VERIFIER NOTES--
The original text is conveying the intended sentiment, namely that: despite primarily being a mechanism to provide both confidentiality and integrity protection, ESP can also be configured in a mode that only provides integrity protection and not confidentiality protection. Such a mode is essentially directly analogous to what AH provides, and thus this statement supports the downgrading of AH support to only a MAY-level requirement.

Errata ID: 2183
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 5.1. says:

There is no requirement that an 
implementation buffer the packet if 
there is a cache miss.

It should say:

There is no requirement that an 
implementation buffers the packet if
there is a cache miss.

Notes:

typo
--VERIFIER NOTES--
original text was grammatically correct.

Errata ID: 2661
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Bob Briscoe
Date Reported: 2010-12-04
Rejected by: Sean Turner
Date Rejected: 2011-03-10

Section header block says:

Obsoletes: 2401

It should say:

Obsoletes: 2401
Updates: 3168

Notes:

RFC 4301 updates RFC 3168 but does not indicate this in its header block.

Specifically, RFC 4301 updates the processing of the ECN field for IPsec tunnel mode that was specified in RFC 3168.
--VERIFIER NOTES--
This action was taken already. The RFC index is already updated and so is the datatracker.

Errata ID: 4709
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Phillip H. Griffin
Date Reported: 2016-06-14
Date Rejected: 2023-08-02

Section Appendix C says:

In the ASN.1 module for this RFC, the following errors prevented syntax 
checking and compilation for programming language code generation:

1. Changed "DEFINITIONS IMPLICIT TAGS = BEGIN" to 
           "DEFINITIONS IMPLICIT TAGS ::= BEGIN"

2. Changed "SPD = SEQUENCE OF SPDEntry" to 
           "SPD ::= SEQUENCE OF SPDEntry"

3. Changed 
   "parameters  ANY -- DEFINED BY algorithm } -- defined outside" to
   "parameters  ANY } -- defined outside"

4. Changed "SPDEntry = CHOICE" to "SPDEntry := CHOICE"

5. Changed "IPsecEntry = SEQUENCE" to "IPsecEntry ::= SEQUENCE"

6. Changed "BypassOrDiscardEntry = SEQUENCE" to 
           "BypassOrDiscardEntry ::= SEQUENCE"

7. Changed "InOutBound = CHOICE" to "InOutBound ::= CHOICE"

8. Changed "iso(1) org (3) dod (6)" to 
           "iso(1) identified-organization (3) dod (6)"

A correct ASN.1 module follows in the "Corrected Text" field. 



It should say:

SPDModule { 
   iso(1) identified-organization (3) dod (6) internet (1) security (5) 
      mechanisms (5) ipsec (8) asn1-modules (3) spd-module (1) 
}
   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   IMPORTS
      RDNSequence FROM PKIX1Explicit88 { 
         iso(1) identified-organization(3) dod(6) internet(1) 
            security(5) mechanisms(5) pkix(7) id-mod(0) 
               id-pkix1-explicit(18) };

-- An SPD is a list of policies in decreasing order of preference

SPD ::= SEQUENCE OF SPDEntry

SPDEntry ::= CHOICE {
           iPsecEntry       IPsecEntry,               -- PROTECT traffic
           bypassOrDiscard  [0] BypassOrDiscardEntry } -- DISCARDBYPASS

       IPsecEntry ::= SEQUENCE {       -- Each entry consists of
           name        NameSets OPTIONAL,
           pFPs        PacketFlags,    -- Populate from packet flags
                              -- Applies to ALL of the corresponding
                              -- traffic selectors in the SelectorLists
           condition   SelectorLists,  -- Policy condition
           processing  Processing      -- Policy action
}

BypassOrDiscardEntry ::= SEQUENCE {
   bypass      BOOLEAN,        -- TRUE BYPASS, FALSE DISCARD
   condition   InOutBound }

InOutBound ::= CHOICE {
           outbound    [0] SelectorLists,
           inbound     [1] SelectorLists,
           bothways    [2] BothWays }

       BothWays ::= SEQUENCE {
           inbound     SelectorLists,
           outbound    SelectorLists }

       NameSets ::= SEQUENCE {
           passed      SET OF Names-R,  -- Matched to IKE ID by
                                        -- responder
           local       SET OF Names-I } -- Used internally by IKE
                                        -- initiator

       Names-R ::= CHOICE {                   -- IKEv2 IDs
           dName       RDNSequence,           -- ID_DER_ASN1_DN
           fqdn        FQDN,                  -- ID_FQDN
           rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
           keyID       OCTET STRING }         -- KEY_ID

       Names-I ::= OCTET STRING       -- Used internally by IKE
                                      -- initiator

       FQDN ::= IA5String

       RFC822Name ::= IA5String

       PacketFlags ::= BIT STRING {
                   -- if set, take selector value from packet
                   -- establishing SA
                   -- else use value in SPD entry
           localAddr  (0),
           remoteAddr (1),
           protocol   (2),
           localPort  (3),
           remotePort (4)  }

       SelectorLists ::= SET OF SelectorList

       SelectorList ::= SEQUENCE {
           localAddr   AddrList,
           remoteAddr  AddrList,
           protocol    ProtocolChoice }

       Processing ::= SEQUENCE {
           extSeqNum   BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
           seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
           fragCheck   BOOLEAN, -- TRUE stateful fragment checking,
                                -- FALSE no stateful fragment checking
           lifetime    SALifetime,
           spi         ManualSPI,
           algorithms  ProcessingAlgs,
           tunnel      TunnelOptions OPTIONAL } -- if absent, use
                                                -- transport mode

       SALifetime ::= SEQUENCE {
           seconds   [0] INTEGER OPTIONAL,
           bytes     [1] INTEGER OPTIONAL }

       ManualSPI ::= SEQUENCE {
           spi     INTEGER,
           keys    KeyIDs }

       KeyIDs ::= SEQUENCE OF OCTET STRING

       ProcessingAlgs ::= CHOICE {
           ah          [0] IntegrityAlgs,  -- AH
           esp         [1] ESPAlgs}        -- ESP

       ESPAlgs ::= CHOICE {
           integrity       [0] IntegrityAlgs,       -- integrity only
           confidentiality [1] ConfidentialityAlgs, -- confidentiality
                                                    -- only
           both            [2] IntegrityConfidentialityAlgs,
           combined        [3] CombinedModeAlgs }

       IntegrityConfidentialityAlgs ::= SEQUENCE {
           integrity       IntegrityAlgs,
           confidentiality ConfidentialityAlgs }

       -- Integrity Algorithms, ordered by decreasing preference

       IntegrityAlgs ::= SEQUENCE OF IntegrityAlg

       -- Confidentiality Algorithms, ordered by decreasing preference

       ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg

       -- Integrity Algorithms

       IntegrityAlg ::= SEQUENCE {
           algorithm   IntegrityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       IntegrityAlgType ::= INTEGER {
           none              (0),
           auth-HMAC-MD5-96  (1),
           auth-HMAC-SHA1-96 (2),
           auth-DES-MAC      (3),
           auth-KPDK-MD5     (4),
           auth-AES-XCBC-96  (5)
       --  tbd (6..65535)
           }

       -- Confidentiality Algorithms

       ConfidentialityAlg ::= SEQUENCE {
           algorithm   ConfidentialityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       ConfidentialityAlgType ::= INTEGER {
           encr-DES-IV64   (1),
           encr-DES        (2),
           encr-3DES       (3),
           encr-RC5        (4),
           encr-IDEA       (5),
           encr-CAST       (6),
           encr-BLOWFISH   (7),
           encr-3IDEA      (8),
           encr-DES-IV32   (9),
           encr-RC4       (10),
           encr-NULL      (11),
           encr-AES-CBC   (12),
           encr-AES-CTR   (13)
       --  tbd (14..65535)
           }

       CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg

       CombinedModeAlg ::= SEQUENCE {
           algorithm   CombinedModeType,
           parameters  ANY } -- defined outside

                                    -- of this document for AES modes.
       CombinedModeType ::= INTEGER {
           comb-AES-CCM    (1),
           comb-AES-GCM    (2)
       --  tbd (3..65535)
           }

       TunnelOptions ::= SEQUENCE {
           dscp        DSCP,
           ecn         BOOLEAN,    -- TRUE Copy CE to inner header
           df          DF,
           addresses   TunnelAddresses }

       TunnelAddresses ::= CHOICE {
           ipv4        IPv4Pair,
           ipv6        [0] IPv6Pair }

       IPv4Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(4)),
           remote      OCTET STRING (SIZE(4)) }

       IPv6Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(16)),
           remote      OCTET STRING (SIZE(16)) }

       DSCP ::= SEQUENCE {
           copy      BOOLEAN, -- TRUE copy from inner header
                              -- FALSE do not copy
           mapping   OCTET STRING OPTIONAL} -- points to table
                                            -- if no copy
       DF ::= INTEGER {
           clear   (0),
           set     (1),
           copy    (2) }

       ProtocolChoice::= CHOICE {
           anyProt  AnyProtocol,              -- for ANY protocol
           noNext   [0] NoNextLayerProtocol,  -- has no next layer
                                              -- items
           oneNext  [1] OneNextLayerProtocol, -- has one next layer
                                              -- item
           twoNext  [2] TwoNextLayerProtocol, -- has two next layer
                                              -- items
           fragment FragmentNoNext }          -- has no next layer
                                              -- info

       AnyProtocol ::= SEQUENCE {
           id          INTEGER (0),    -- ANY protocol
           nextLayer   AnyNextLayers }

       AnyNextLayers ::= SEQUENCE {      -- with either
           first       AnyNextLayer,     -- ANY next layer selector
           second      AnyNextLayer }    -- ANY next layer selector

       NoNextLayerProtocol ::= INTEGER (2..254)

       FragmentNoNext ::= INTEGER (44)   -- Fragment identifier

       OneNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (1..254),   -- ICMP, MH, ICMPv6
           nextLayer   NextLayerChoice }   -- ICMP Type*256+Code
                                           -- MH   Type*256

       TwoNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (2..254),   -- Protocol
           local       NextLayerChoice,    -- Local and
           remote      NextLayerChoice }   -- Remote ports

       NextLayerChoice ::= CHOICE {
           any         AnyNextLayer,
           opaque      [0] OpaqueNextLayer,
           range       [1] NextLayerRange }

       -- Representation of ANY in next layer field

       AnyNextLayer ::= SEQUENCE {
           start       INTEGER (0),
           end         INTEGER (65535) }

       -- Representation of OPAQUE in next layer field.
       -- Matches IKE convention

       OpaqueNextLayer ::= SEQUENCE {
           start       INTEGER (65535),
           end         INTEGER (0) }

-- Range for a next layer field

NextLayerRange ::= SEQUENCE {
   start  INTEGER (0..65535),
   end    INTEGER (0..65535) 
}

-- List of IP addresses

AddrList ::= SEQUENCE {
   v4List  IPv4List OPTIONAL,
   v6List  [0] IPv6List OPTIONAL
}

-- IPv4 address representations

IPv4List ::= SEQUENCE OF IPv4Range

IPv4Range ::= SEQUENCE {    -- close, but not quite right ...
   ipv4Start  OCTET STRING (SIZE (4)),
   ipv4End    OCTET STRING (SIZE (4)) 
}

-- IPv6 address representations

IPv6List ::= SEQUENCE OF IPv6Range

IPv6Range ::= SEQUENCE {    -- close, but not quite right ...
   ipv6Start  OCTET STRING (SIZE (16)),
   ipv6End    OCTET STRING (SIZE (16)) 
}

END


Notes:

Note that I included an ASN.1 module stub to resolve an imported value in the module.

PKIX1Explicit88 {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)
}
DEFINITIONS EXPLICIT TAGS ::= BEGIN

RDNSequence ::= SEQUENCE {}

END -- PKIX1Explicit88 --
--VERIFIER NOTES--
This is for RFC4301 and tries to fix the ASN.1 in Appendix C.
The proposed changes uses lines which are not part of the
RFC4301, i.e., the "=" -> "::=" that are listed as needed to
be done, are already "::=" in the RFC4301.

The only other proposed changes are to remove
"-- DEFINED BY algorithm" from one location, but it
leaves it in in few other places. It also proposes to change
iso(1) org (3) dod (6)" to "iso(1) identified-organization (3)
dod (6) which might be correct, but is not needed.

Report New Errata



Advanced Search