Search RFCs

RFC Editor

Found 6 records.

Status:Verified (4)

RFC 3779, "X.509 Extensions for IP Addresses and AS Identifiers", June 2004

Errata ID:2537
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-09-30
Verifier Name: Sean Turner
Date Verified: 2011-02-23

Section 2.2.3.9 says:

   To simplify the comparison of IP address blocks when performing   certification path validation, a maximum IP address MUST contain at   least one bit whose value is 1, i.e., the subsequent octets may not   be omitted nor all zero.

It should say:

Text should be deleted.

Notes:

There are a number of different issues relative to this text that need to be addressed.

1. This text implicitly change the rules for encoding a maximum value. As an example the address 0.0.0.255 is encoded as 03 03 00 00 00 00 according to the rule " The BIT STRING for the maximum address results from removing all the least-significant one-bits from the maximum address."

2. The rule in no way simplifies any comparisions of IP address blocks. If one really wishes to simplify the comparison then one needs to change the rule for maximum addresses to remove all but the last least-signficant one-bit from the address. However it is not clear that even this would really simplify the comparison in any significant way.

If you look at the example in 2.2.3.9 - tis is not clear how having the one bit at the top of the encoding helps make the comparisons any easier - but it satisfies the requirment that atleast one bit is a 1. If the maximum value ws encoded as 1000 1 (0x3 0x02 0x03 0x84) - a bitwise comparision routine could make for a simplified a < b comparison (looking at only the top 5 bits of the address to be compared.)

Errata ID:6792
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Theo Buehler
Date Reported: 2021-12-21
Verifier Name: Benjamin Kaduk
Date Verified: 2021-12-25

Section Appendix B says:

   30 3d                       Extension {      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7      01 01 ff                   critical      04 2e                      extnValue {         30 2c                     IPAddrBlocks {            30 10                    IPAddressFamily {               04 03 0001 01           addressFamily: IPv4 Unicast                                       IPAddressChoice               30 09                     addressesOrRanges {                                           IPAddressOrRange                  03 02 00 0a                addressPrefix    10/8                                           IPAddressOrRange                  03 03 04 b010              addressPrefix    172.16/12                                         } -- addressesOrRanges                                     } -- IPAddressFamily            30 07                    IPAddressFamily {               04 03 0001 02           addressFamily: IPv4 Multicast                                       IPAddressChoice               05 00                     inherit from issuer                                     } -- IPAddressFamily            30 0f                    IPAddressFamily {               04 02 0002              addressFamily: IPv6                                       IPAddressChoice               30 09                     addressesOrRanges {                                           IPAddressOrRange                  03 07 00 200100000002      addressPrefix   2001:0:2/47                                         } -- addressesOrRanges                                     } -- IPAddressFamily                                   } -- IPAddrBlocks                                 } -- extnValue                                  } -- Extension

It should say:

   30 3d                       Extension {      06 08 2b06010505070107     extnID        1.3.6.1.5.5.7.1.7      01 01 ff                   critical      04 2e                      extnValue {         30 2c                     IPAddrBlocks {            30 10                    IPAddressFamily {               04 03 0001 01           addressFamily: IPv4 Unicast                                       IPAddressChoice               30 09                     addressesOrRanges {                                           IPAddressOrRange                  03 02 00 0a                addressPrefix    10/8                                           IPAddressOrRange                  03 03 04 ac10              addressPrefix    172.16/12                                         } -- addressesOrRanges                                     } -- IPAddressFamily            30 07                    IPAddressFamily {               04 03 0001 02           addressFamily: IPv4 Multicast                                       IPAddressChoice               05 00                     inherit from issuer                                     } -- IPAddressFamily            30 0f                    IPAddressFamily {               04 02 0002              addressFamily: IPv6                                       IPAddressChoice               30 09                     addressesOrRanges {                                           IPAddressOrRange                  03 07 00 200100000002      addressPrefix   2001:0:2/48                                         } -- addressesOrRanges                                     } -- IPAddressFamily                                   } -- IPAddrBlocks                                 } -- extnValue                                  } -- Extension

Notes:

b010 represents 176.16/12, the hex representation of 172 is ac, so it should be ac10.

The IPv6 addressPrefix in question is 2001:0:2/48, not 2001:0:2/47, as explained in the text before the example.

Errata ID:836
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randy Bush
Date Reported: 2006-06-21

Section 3.2.3.1 says:

The ASIdentifiers type is a SEQUENCE containing one or more forms ofautonomous system identifiers -- AS numbers (in the asnum element) orrouting domain identifiers (in the rdi element).  When the ASIdentifiers typecontains multiple forms of identifiers, the asnumentry MUST precede the rdi entry.  AS numbers are used by BGP, androuting domain identifiers are specified in the IDRP [RFC1142].

It should say:

[see Notes]

Notes:

IDRP was never defined in an RFC, only by ISO 10747.

from pending

Errata ID:1886
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Bobo
Date Reported: 2009-09-21
Verifier Name: Sean Turner
Date Verified: 2010-04-19

Section 2.1.1 says:

   An IPv6 address is a 128-bit quantity that is written as eight   hexadecimal numbers, each in the range 0 through ffff, separated by a   semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6   address.  IPv6 addresses frequently have adjacent fields whose value   is 0.  One such group of 0 fields may be abbreviated by two   semicolons ("::").

It should say:

   An IPv6 address is a 128-bit quantity that is written as eight    hexadecimal numbers, each in the range 0 through ffff, separated by a    colon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 address.   IPv6 addresses frequently have adjacent fields whose value is 0.  One   such group of 0 fields may be abbreviated by two colons ("::").

Notes:

"semicolon" should be "colon"
Added reference to RFC4291.
Verifier: Forward reference to RFC4291 is inappropriate.

Status:Held for Document Update (2)

RFC 3779, "X.509 Extensions for IP Addresses and AS Identifiers", June 2004

Errata ID:7653
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2023-09-22
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12

Section 3.2.3 says:

Section 3.2.3.8:The ASRange type is a SEQUENCE consisting of a min and a max element,and is used to specify a range of AS identifier values.

It should say:

Section 3.2.3.8:The ASRange type is a SEQUENCE consisting of a min and a max element,and is used to specify a range of AS identifier values. The min and maxelements MUST specify two distinct AS identifiers.

Notes:

The introduction in section 1 stresses that the objective of the encoding rules in section 2 and section 3
is to produce unique encoding and minimal size encoding of the information.

Allowing ASRanges where the minimum value is the same as the maximum value clearly violates the
objective of specifying a canonical form (in order to produce a unique representation); however the
specification as-is doesn't forbid min & max to be the same value. The corrected text addresses this.

Note: erratum edited per https://mailarchive.ietf.org/arch/msg/pkix/iZnCd58xgl1C47GSeFemAU9CF1g/

Errata ID:1887
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Bobo
Date Reported: 2009-09-21
Held for Document Update by: Tim Polk

Section References says:

   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6               (IPv6) Addressing Architecture", RFC 3513, April 2003.   [RFC3281]   Farrell, S. and R. Housley, "An Internet Attribute               Certificate Profile for Authorization", RFC 3281, April               2002.   [S-BGP]     S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway               Protocol (S-BGP)," IEEE JSAC Special Issue on Network               Security, April 2000.

It should say:

   [RFC3281]   Farrell, S. and R. Housley, "An Internet Attribute               Certificate Profile for Authorization", RFC 3281, April               2002.   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6               (IPv6) Addressing Architecture", RFC 3513, April 2003.   [RFC4291]   R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",               RFC 4291, February 2006   [S-BGP]     S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway               Protocol (S-BGP)," IEEE JSAC Special Issue on Network               Security, April 2000.

Notes:

Section is "Informational References" but this doesn't fit in the Section field above.
References were out of alphabetical order -- RFC3281 should come before RFC3513.
Added reference RFC4291

Report New Errata