Skip to main content

X.509 Extensions for IP Addresses and AS Identifiers
RFC 3779

Yes

(Allison Mankin)
(Russ Housley)

No Objection

(Alex Zinin)
(Bill Fenner)
(Jon Peterson)
(Ned Freed)
(Ted Hardie)
(Thomas Narten)

Note: This ballot was opened for revision 03 and is now closed.

Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Russ Housley Former IESG member
Yes
Yes () Unknown

                            
Steven Bellovin Former IESG member
Yes
Yes (2003-11-17) Unknown
This draft mixes syntax -- how a certificate should represent prefixes -- with policy (the notion that prefixes come from RIRs or ISPs).  Is that right?

Is the special case encoding for 0/0 legal DER?  Or will it break some parsers?
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2003-11-20) Unknown
According to our ID-NITS, IP addresses used in examples
should use a predefined set of address.
So
   10.5.0.5 is an example of an IPv4 address.
is not allowed (rfc3330)

There are more samples in this doc
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2003-11-04) Unknown
Since multiple WGs have been involved in this effort (as Russ said on email), perhaps that should be mentioned in the "WG summary" writeup?
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection (2003-11-19) Unknown
A couple of (probably ignorant) questions:

This document seems to describe an ASN.1 encoding for IP addresses.
Since we already have defined ways to express IP addresses in 
ASN.1 (for MIBs), why do we need another one?

Since all of the IP address encodings use the same type, is there 
some other context that makes it clear whether you are looking at 
an IPv4 address, an IPv6 address, a prefix (of either type) or
an address range (of either type)?

Editorial Comments:

   IP v4 address - a 32-bit identifier written as four decimal numbers,
      each in the range 0 to 255, separated by a ".".  10.5.0.5 is an
      example of an IPv4 address.

   IP v6 address - a 128-bit identifier written as eight hexadecimal
      quantities, each in the range 0 to ffff, separated by a ":".
      2001:0:200:3:0:0:0:1 is an example of an IPv6 address.  One string
      of :0: fields may be replaced by "::", thus 2001:0:200:3::1
      represents the same address as the immediately preceding example.
      (See [RFC3513]).

> s/IP v4/IPv4/
> s/IP v6/IPv6/

> These are both used in the common form (IPv4, IPv6) later in the
> document.  Also the examples included here are included again 
> later, which seems redundant.

   prefix - a bit string that consists of some number of initial bits of
      an address, written as an address followed by a "/", and the
      number of initial bits.  10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64
      (or 2001:0:200:3::/64) are examples of prefixes.  A prefix is
      often abbreviated by omitting the less-significant zero fields,
      but there should be enough fields to contain the indicated number
      of initial bits.  10.5/16 and 2001:0:200:3/64 are examples of
      abbreviated prefixes.

>> This definition doesn't match the definition given later in the
>> document which is:

   An address prefix is a set of 2^k continuous addresses whose more-
   significant bits are identical.  For example, the set of 512 IPv4
   addresses from 10.5.0.0 through 10.5.1.255 all have the same 23 most-
   significant bits.  

>> I happen to like the first definition better, but I could live
>> with the second.  We just shouldn't include two different defs
>> in the same document.

   The special case of all IP address blocks, i.e., a prefix of all
   zero-bits -- "0/0", MUST be encoded per the DER with a length octet
   of one, an initial octet of zero, and no subsequent octets:
Ned Freed Former IESG member
(was Discuss, No Objection) No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Thomas Narten Former IESG member
No Objection
No Objection () Unknown